Re: [CDBI] Why does CDBI not populate the object on insert

On Thu, Mar 05, 2009 at 04:10:10PM -0800, Michael G Schwern wrote:
> 
> And then you have data normalization at the database level rather than the
> application level.  Capitalization, phone numbers, credit card numbers,
> province names, country names... all are better done in the database than in
> individual applications to keep data integrity.

I'm a huge fan of very tight constraints and data checking in the
database -- in my view the database is really the application and the
constraints must keep it in a stable state.  But, I can't think of any
place where I use a trip to the database and back for normalization.

I suspect if I thought about it a while I could find an exception to
that, but it it would be very rare in my case.


> Honestly, lazy loading is probably the biggest architectural mistake I made in
> CDBI.  It seemed like a good idea at the time in 1999, with limited memory and
> I was working on a message storage system (lots of small headers, big body)
> but honestly it made the code way more complicated than it should be and
> probably drags performance down more than it speeds up.  I should have just
> made each message join from header and body tables but that would have
> required good join support early on and I suck at joins.

Is the lazy loading expensive when not used? That is where Essential
is tuned for the columns used?

> >     $country = $hood->city->state->country;
> 
> Speaking of sucking at joins, that's always going to suck in CDBI.

Sure, normally that would be very slow, which is what caught my
attention.  But, in this specific case I had created $state, from
$counry, and $city from $state, and so on, so all the related objects
were around.  There's was no real reason to go back to the database
(except for reasons discussed today).

> Consider using Class::DBI::Sweet or DBIx::Class both of which I
> believe can model the above as a join instead of a string of
> selects.

One of the reasons I still like CDBI is that it's a pretty
simple ORM, and when I need more complex joins (which is very common
in anything but the simplest application) I use set_sql().  I find SQL
a nice clean way to write database queries. ;)



-- 
Bill Moseley.
[email protected]
Sent from my iMutt