RE: [CDBI] Multiple records

> I have come across a tricky problem and would like advice for how to

Certainly a valid point about overhead with validation. Yet, there is an
order of magnitude difference between normalization of , say, s/\s//g and a
database insert.  I looked at cdbi->create and decided to stick with
normalization, validation, but skip triggers.  makes sense not to have them.
My concern was primarily esthetic.  I hate the idea of using an OO framework
and then getting around it without some thought.

Thanks for the advice.  It made me feel better. :-)

-----Original Message-----
From: Michael Peters [mailto:mpeters@xxxxxxxxx.xxx]
Sent: Tuesday, September 06, 2005 8:44 AM
To: Kate Yoak
Cc: classdbi@xxxxx.xxxxxxxxxxxxxxxx.xxx
Subject: Re: [CDBI] Multiple records

Kate Yoak wrote:
> I have come across a tricky problem and would like advice for how to
> handle it best.
> Let's suppose I have a Bucket which has_many Water::Drop's.  Now, it's a
> really large bucket, and we may be able to put thousands of drops in it
> (or we might just put one).
>
> It would be nice to be able to store them all at once.  One-at-a-time
> method might be just a tad slow.

Are you worried primarily about all the objects being created or the
number of calls to the database that make it slow?

> OK, so we make a create_many method in the parent class.  Unlike the
> regular create() method it does not return any objects - it's for
> writing to the database and nothing else.  Presumably, there is no need
> to generate thousands of objects at once - they can be retrieved later.
> There is a design problem with this approach: data validation routines
> are not being called.  Triggers are not either.  A lot of implied
> functionality breaks (some that I am probably not aware of).

Calling all of those triggers and constraint methods is going to a 'tad
slow' too.

> I can certainly look at the code for Class::DBI::create() and make sure
> I do everything that's necessary.  But before I plunge ahead, has anyone
> a) encountered this situation before

Nope, sorry
b) thought of a clever way to solve it

Are you getting a lot of data from some trusted source? Do you really
need constraints and triggers? If you do, I assume you could call them
yourself, using the subs you give to C::DBI and just iterate over the
data. If it's a large set, you might even consider using some bulk
loading facility that your RDBMS provides (like LOAD DATA INFILE in MySQL).

> c) decided it's the wrong way to think about it d) has general advice.

Class::DBI is all about object-to-row mapping. If you encounter a
situation where that gets in the way, or becomes too inefficient (when
compared to straight SQL/DBI) then I'd suggest you just use DBI
(accessed through db_Main() if you keep the same connection and use it
in your data classes).

--
Michael Peters
Developer
Plus Three, LP

_______________________________________________
ClassDBI mailing list
ClassDBI@xxxxx.xxxxxxxxxxxxxxxx.xxx
http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi