in reply to Looking for DBIx::Class tutorials and examples

I don't have any good tutorials or examples to link right now but I wanted to say it's not your fault. DBIC covers some complicated ground and the docs miss many edge cases, gloss or skip some things which are simple after you understand them, some unusual points of functionality are undocumented or documented three modules away in places like SQL::Abstract or SQL::Translator, et cetera. Since we're on the topic, reading the internals to learn more is quite difficult. So, if someone recommends that, you might keep asking. :)

The DBIC mailing list is friendly and some of the core devs hang out on the irc channel often. So, if you can break your hurdles down to manageable bits, you can definitely get help and sometimes spark doc patches doing so. You can ask here too, of course. If you want to write a tutorial as you learn, it's a great time; it could be part of: The Enlightened Perl Iron Man Competition. Most DBIC power users forget the things they needed to learn to get into it.

Update: I forgot half the point: It's difficult but I have found it entirely worth it. With DBIC I can do things like develop DB schemas on the fly because my code will simply adjust itself to whatever harebrained table/relationship changes I want to try out. Inflation, versioning, auto-deployment, result set extension and chaining, and more have saved me at least 10x the time I put into picking up DBIC and the ratio only improves over time. So, stick with it. :)

Update 2: I found this really helpful dbix-masterclass.xul though it's not an entry level "talk."

Update 2017-04-23: linked module names.

  • Comment on Re: Looking for DBIx::Class tutorials and examples

Replies are listed 'Best First'.
Re^2: Looking for DBIx::Class tutorials and examples
by morgon (Priest) on Apr 23, 2009 at 18:41 UTC
    Ok, thanks a lot, I'll play with it a little more but I am getting frustrated...

    Here's e.g. one problem I have:

    I have two classes/tables with a one-to-many relationship.

    So in the one I do

    # in SMU::Bubba __PACKAGE__->has_many( hubbas => 'SMU::Hubba' );
    In the other I do:
    # in SMU::Hubba __PACKAGE__->belongs_to( bubba => 'SMU::Bubba' );
    So now I can navigate from a Bubba-instance to a Hubba-instance like this:
    my $hubba = $bubba->bubbas->find($id);
    But now when I want to navigate back from the Hubba to the Bubba via
    $hubba->bubba
    I can do that and it gives me a Bubba-instance, but I am getting a different instance of the class (describing the same row) which is causing me problems as I want to be able to walk the whole graph up and down and then do one update.

    Maybe I really do it all in plain DBI...

      I think this line is supposed to be hubbas, not bubbas, just to clarify-

      $hubba = $bubba->hubbas->find($id);

      That's a bit odd way to do it. hubbas called on a bubba is going to return the list of the hubbas that belong to it. I didn't even realize your syntax would work (calling a method on the hubbas call). I can't test it now but it's probably because the context returns an iterator instead of an object list and the iterator will allow the find call.

      You probably want, should be using, the search_related method. $hubba->bubba returns the object representing the result/row of that bubba. It's not a resultset and I don't think context manipulation, like the hubbas call can change that.

      About DBI... DBI is great! DBIC is built on it and its various engines. That said, DBIC buys you 100 things DBI doesn't and they are the things that most devs end up rolling themselves in some form or another and doing 1) badly, 2) without tests, 3) in a dead-end way, 4) without public release, 4) buggy, 5) etc. I have a rant brewing for AM below. Don't know if I'll bother tonight but that kind of thinking is what dooms software projects that end up growing to be miserable dung heaps for the devs who inherit them; c.f., me.

        Sorry for the typo.

        Just to clarify what I want to achieve:

        I have objects containing other objects (Bubbas containing several Hubbas in the above).

        What I want to do now is to load the whole object (or object-graph if you want) from the database and then do some processing on it.

        The processing consists of the container-object receiving a message (which comes from a queue) which it then passes on to some of the contained objects which in turn may have to inform the container about something in the course of their processing the message.

        After all this processing is done (the whole graph is updated) I then want to store the whole graph again in one transaction (which also will contain the dequeuing of the message).

        My problem really is that I don't have a good understanding about the intention of the several DBIx::Class components and the whole underlying philosophy (e.g. naively I had assumed that the framework would assure that you only ever could have one instance per primary key but that does not seem to be the case...)

        And I have used DBI a lot and fully agree with what you say regarding the advantages of a proper ORM-framework, I just wish I would understand it...

        But many thanks