Re^2: Looking for DBIx::Class tutorials and examples

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' );
[download]

In the other I do:

# in SMU::Hubba
__PACKAGE__->belongs_to( bubba => 'SMU::Bubba' );
[download]

So now I can navigate from a Bubba-instance to a Hubba-instance like this:

my $hubba = $bubba->bubbas->find($id);
[download]

But now when I want to navigate back from the Hubba to the Bubba via

$hubba->bubba
[download]

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...

Comment on Re^2: Looking for DBIx::Class tutorials and examples Select or Download Code

Replies are listed 'Best First'.
Re^3: Looking for DBIx::Class tutorials and examples by Your Mother (Archbishop) on Apr 23, 2009 at 18:58 UTC
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.	[reply] [d/l] [select]
Re^4: Looking for DBIx::Class tutorials and examples by morgon (Priest) on Apr 23, 2009 at 21:24 UTC
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	[reply]