[Dbix-class] Newbie question

Andreas Mock andreas.mock at drumedar.de
Mon Mar 16 13:46:28 GMT 2009


> -----Ursprüngliche Nachricht-----
> Von: "Ian Wells" <ijw at cack.org.uk>
> Gesendet: 16.03.09 13:37:12
> An: "DBIx::Class user and developer list" <dbix-class at lists.scsys.co.uk>
> Betreff: Re: [Dbix-class] Newbie question

Hi Ian,


> I think you're approaching the question from the other end to how
> DBIx::Class tends to represent it.
> 
> DBIx::Class tends to think of what you get back as an object
> representing a row in the DB, which represents a concept (e.g. a
> book).

That chain is interesting and raises exactly a part of the question I do have.
Does this force me to think of an object as something which has to (!) be
stored in ONE table besides of collections which are stored as related
table entries. So, e.g. can I have an object whose attributes are stored
in two tables? (Don't think about sense or nonsense)

> You sound like you're coming from a .NET or Java background where you
> think of the database is a stored representation of an object which
> represents a book.

No, no...there are so many frameworks named ORM with subtle differences
and functional ranges, that I just want to understand the concept of DBIC.
I am (was) confused by the database centric view and don't know the limitations
this does imply.

> 
> It's much the same thing in the end.

With emphasis on "much"...  ;-)

> 
> > Are these rows "Book"-Objects???
> 
> Yes.

OK.

> 
> > Or do I have to use these row-objects with Book-attributes to initialize/instanciate
> > a Book-Object. (an object with other methods besides methods usfull for persistence)
> > Or is this by convention the same?
> 
> You get a resultset, which you can loop over to get individual Book
> result objects, and result object (a) represents a book and (b) is a
> loaded version of a database row in the Book table.

Once again the question about that one-to-one mapping between
a database table and an object instance.

A production example to clarify my scenario:
We do have objects (O) which consist of attribues (A) which are
stored in a table O with columns A just as DBIC would model it.
But we do also have sparse attributes (B) (attributes which are very often
NULL) which are not stored as columns of the "base" table O but as rows
of a - let's call it attribute table - where each "not null"-attribut B of O is a
row in that table with a key consisting of a class identifier,
an object identifier (O.id) and an attribute identifier.

After loading this object I want to see that object in a flat way. This
"attribute collection" shall show up as "normal" (columns) attributes.
While using the object from the application perspective I don't want to
know that there are some attributes stored as columns and some as
entries in a related table.

The difference to the documented examples (Artist, CD, Tracks) is that there
you do have a semantic of collections. The application does know of a
attribut of the object being a list of something. Therefore it's o.k. to deal with
it in a manner which is appropriate to collections. (You called it concept)
The concept of has_many, is_related, etc. fit there properly.

So the remaining question: How can I achieve to hide the way "normal"
(not collection) attributes are stored in one or more tables?

> 
> The Book object type can be changed: you can add additional methods
> and properties to the book by changing the object's code.  So the
> objects that work with DBIx::Class are not *only* for DBIx::Class use,
> you can add business logic there too.

Ok. Classical inheritance of DBIx::Class for persistence.


Best regards
Andreas




More information about the DBIx-Class mailing list