Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • ... and how many of those were from UNIVERSAL:: ? :)

    • via UNIVERSAL: VERSION
      via UNIVERSAL: a_sub_not_likely_to_be_here
      via UNIVERSAL: can
      via UNIVERSAL: isa

      The full list of classes involved:

      Class::Accessor::Grouped
      Class::C3::Componentised
      DBIx::Class
      DBIx::Class::Co mponentised
      DBIx::Class::Core
      DBIx::Class::InflateColumn
      DBIx::Class::Relatio nship
      DBIx::Class::Relationship::Accessor
      DBIx::Class::Relationship::BelongsTo
      DBIx::Class::Relationship::HasMany
      DBIx::Class::Relationship::HasOne
      DBIx::C lass::Relationship::Helpers
      DBIx::Class::Relationship::ManyToMany
      DBIx:

  • Well, if 255 methods/27 classes are too much for your taste, change ORM!

    DBIx::DataModel [cpan.org] will only cost you about 50 methods in 3 classes (the exact number depends on how many relationships there are between this table and other tables).

    (sorry, DBIC folks, I couldn't resist ...)

    • Well, I doubt I could push that through at work, but I suspect that I'd be inclined to go the SQL dictionary route. Still, just glancing at it, DBIx::DataModel looks interesting.

      • No no, no SQL dictionary, you want to look at Fey.

        • Ah, that looks lovely! And yes, better than a dictionary.

          • It is lovely! I have been using it for a while and it has worked out every bit as well as I had hoped for. Sometimes I had to change the shape of my queries a little to accommodate it, but I have yet to run into a wall due to the fundamental design. There were stumbling blocks in cases where I ran into corners that Dave hadn’t built out yet – f.ex. when I first started with it, it failed if you tried to join against a table alias, which I needed for my tag (as in “folksonomy”) joins.

            • I know this is rather irrational - but the thing that off puts me from Fey is that the connection is kept in a singleton. This leads to the need of not very DRY declarations: package Forum::Model::User; use Forum::Model::Schema; use Fey::ORM::Table; has_table( Forum::Model::Schema->Schema()->table('User') ); It could be just: package Forum::Model::User; use base Forum::Model::Schema; has_table( 'User' ) I am acustomed to the DBIC way of having a normal Schema object that keeps the connect
              • I’m talking only about Fey::SQL, not Fey::ORM. I don’t use Fey::ORM at all.

                But do to take up your concerns with Dave – he’s a reasonable guy.

                • I've already asked him about the possibility of shortening the declarations. The answer was that that it probably mean too much magic - which is, in my opinion, only the consequence of using 'magic' signletons in the first place. I will not ask him about getting rid of that - since I would not expect any productive answer - this is too basic design choice to change in the mid-work.
                  • Ah. Well, I am happy to remain blissfully unaware of these issues and to stick with Fey::SQL. :-)