[Dbix-class] Newbie question

Scott Pham (scpham) scpham at cisco.com
Mon Mar 16 14:54:35 GMT 2009


> -----Original Message-----
> From: Andreas Mock [mailto:andreas.mock at drumedar.de]
> Sent: Monday, March 16, 2009 9:46 AM
> To: DBIx::Class user and developer list
> Subject: Re: [Dbix-class] Newbie question
> 
> > -----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

To me it really sounds like you mean business logic?

You have the DBIC layer(DB), then you have application layer(business)?



More information about the DBIx-Class mailing list