Hi!
I am currently evaluating DBIx::Class as a ORM-solution for a new system and I
wonder either my design is flawed or DBIx::Class simply is not the right tool
for me...
I have a number of classes (all based on Moose) that I need to persist in an
Oracle-database. The application is driven by messages that are received via
Oracle Advanced Queuing.
To process a message I have to retrieve a number of collaborating objects from
the database (which then in memory form some sort of tree or graph) where calls
are made from e.g. a child-object to a parent-object, and the other way around
to finally reach an end-state at which point the whole object-graph should be
persisted again to the database.
So the whole thing should work like this:
1) dequeue message
2) build object-graph
3) process message in the graph
4) update graph in database
5) commit
I.e. the final commit not only commits all changes to the object-graph but also
the dequeuing of the message in one transaction.
In such a context I would like each database-entity (given by it's primary key)
to be represented by exactly one instance on the object-level (which Class::DBI
actually does) but the philosophy of DBIx::Class seems to be different, for
instance if I do this:
my $h1 = $schema->resultset('Hubba')->find(1);
my $h2 = $schema->resultset('Hubba')->find(1);
I get two different instances both representing the same database-row which
makes it a bit harder to build the graph I have in mind.
Can someone please give me some advice here?
(I have had a look at DBIx::Class::SingletonRows but I don't really like the
way it does it's business.)
Many thanks!
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
