Sam Tregar wrote:
Sounds cool. I'm curious about your database access approach:
Thanks - I'm not solid on the database approach and I welcome input.
What will the plugin do with just a DBI connect string? Will it use Class::DBI::Loader internally?
That was my thought process last night - to use Class::DBI::Loader underneath the covers, but allow the developer to also pass in a staticly set of Class::DBI classes in case they want to bypass the time that ::Loader takes at compilation to dynamically build classes.
Also, that seems to imply that you'd use the plugin with an entire database. That seems unlikely to me.
You bring up a good point - I was thinking of opening the entire database, but I agree that it would be pretty unlikely; there may be join tables or application-internal tables. Perhaps we put in another method in which it would accept an arrayref of table names, including a special name for all tables (i.e. __ALL__ ??).
Or maybe an arrayref of Class::DBI classes, which map to the table and would also define the relationships between the tables?
That's one of the weaknesses (or is it?) of ::Loader - missing out on the relationships in case the user adds or deletes a record.
Side note: I also realized I chopped out the Synopsis part of the POD - not earth-shattering, but I just put that back in.
- Jason
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/suppressed/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.