On Monday, December 10, 2001, at 08:48 AM, Tim Bunce wrote:
> At this point I'd just like to solicit some feedback from anyone
> who's used DBIx::AnyDBD and got any ideas or comments etc about it
> and how it could be improved.
>
I read over the docs and had a good night's sleep on this subject
and now have the following points to make:
1 - In the examples directory, it bothers me that
Example::DB::Default has 2 different types of things. On the one
hand, it has generic SQL construction methods. On the other, it
has a number of SQL operations for a particular app. I think the
app-specific SQL belongs in Example::DB::Methods or something.
And another thing, having a function for every SQL statement
implies that they will all be in memory for the life of the
application. I have worked at companies where we have 5000+
queries. In this case, memory for all the strings becomes and
issue. In this case, something like my module SQL::Catalog would
have been useful, because all SQL strings are loaded and dropped
from main memory for each query. I admit that this is time
consuming, but one can't have the fastest system and the most
memory efficient system.
However, if something is going to be a part of DBI, shouldn't it
be flexible enough to allow optimal query service in terms of
either speed (in-memory functions as is done now) or memory
(lexically scoped query strings which are destroyed on function
exit)?
2 - I was a bit surprised that the subclasses in the examples
hiearchy were so SQL oriented. I had expected to see "business
operations" like "register_order", "load_customer_id", etc, etc.
The SYNOPSIS does show one line which is a business operation:
my @users = $db->get_users(); # called from Example/DB/Pg.pm
but (a) it is not implemented and (b) it is not clear to me where
in the object hierarchy business operations should be with
respect to the AnyDBD classes. Ahh, this was answered
above.Theyare in Default.pm and *textually* separated with the
comment:
###############################################################
# Main SQL methods here
###############################################################
when in fact my feeling is they should be in their own class somewhere.
3 - I am on the Postgresql mailing lists and outer joins can be
done in 7.1.3 using "OUTER JOIN ON" and not the (+) operator of
Oracle. But your Pg.pm throws an exception:
sub _outer_join
{
die "Cannot do outer joins in Postgres. This method needs to
be hand coded\
for Postgres.";
}
which is no longer true for Postgresql. Which of course brings up
the issues of creating subclasses not just on database type
(oracle, mysql, etc) but also for various versions of the
database (postgresql pre-7.1.3 versus 7.1.3 onward)
4 - DBIx::AnyDBD is nice for "runtime-SQL", that is SELECT,
UPDATE, DELETE, INSERT, but it does not show support for
"admin-SQL", in other words for table creation. My favorite
module for this is Marcel Grunaer's DBIx::Renderer.
5 - Although I think I know the answer to this, it was not stated
in direct terms enough for me. So, only the particular subclass
(MyClass::Oracle or MyClass::Pg or MyClass::MySQL) is required
dynamically right? Not all 3 are used by default right?
6 - In Tim's MySQL to Oracle conversion (it usually seems to go
the other way these days), my guess is he will be creating stored
procedures in many places where Perl code was running
client-server SQL inline.
It will be interesting to see how he abstracts this process.
