[Dbix-class] Designing a system with DBIx::Class

[Rob Kinyon]

On Thu, Apr 30, 2009 at 10:21, Morgon Hed <morgonhed at yahoo.com> wrote:
>
> 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.)

Sounds like Oracle isn't the right solution for you - this is a very
non-relational dataset. My guess is that you really want a
non-relational datastore. I'd look at something like KiokuDB or
CouchDB.

-- 
Thanks,
Rob Kinyon