This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: "Stas Bekman" <stas@stason.org>, "clayton cottingham"
<drfrog@smartt.com>
From: "Perrin Harkins" <perrin@elem.com>
Subject: Re: dbi abstraction layer on perlmonks
Date: Fri, 3 Aug 2001 10:27:08 -0400
> The mod_perl guide has an abstraction DBI layer module.
> http://perl.apache.org/guide/databases.html#The_My_DB_module
> I like it very much, but hey it was developed by me :)
Maybe the guide should include links to the most mature peristence
abstraction layer projects out there:
- Class::DBI
- Alzabo
- Tangram
- SPOPS
===
To: Perrin Harkins <perrin@elem.com>
From: Stas Bekman <stas@stason.org>
Subject: Re: dbi abstraction layer on perlmonks
Date: Sat, 4 Aug 2001 00:01:47 +0800 (SGT)
On Fri, 3 Aug 2001, Perrin Harkins wrote:
> > The mod_perl guide has an abstraction DBI layer module.
> > http://perl.apache.org/guide/databases.html#The_My_DB_module
> > I like it very much, but hey it was developed by me :)
>
> Maybe the guide should include links to the most mature peristence
> abstraction layer projects out there:
> - Class::DBI
> - Alzabo
> - Tangram
> - SPOPS
I suppose that could fit into the help.pod. Otherwise it's not directly
related to mod_perl, and the guide has to start shrinking rather than
growing. Of course if any of the above have special issues with mod_perl
they *should* be noted in the guide.
That's said, I should remove the MyDB module from the guide.
I'd also start working on the new docs for mod_perl 2.0, so I can see an
extended chapter on databases and persistence layers in the users guide.
Perrin, would you like to be the database chapter pumpkin? :) You are the
templates pumpkin already anyways :)
===
To: "Stas Bekman" <stas@stason.org>, "clayton cottingham"
<drfrog@smartt.com>,
From: "David Harris" <dharris@drh.net>
Subject: RE: dbi abstraction layer on perlmonks
Date: Fri, 3 Aug 2001 16:40:10 -0400
Stas Bekman [mailto:stas@stason.org] wrote:
> The mod_perl guide has an abstraction DBI layer module.
> http://perl.apache.org/guide/databases.html#The_My_DB_module
> I like it very much, but hey it was developed by me :)
>
> Note that I've improved the code since then, but the online version wasn't
> updated yet. The concept didn't change though.
>
> If anybody likes the concept and want to take the ownership and release it
> on CPAN, let me know.
I looked at your My:DB library and this seems to me be a re-write of the SQL
language and DBI that: (a) accepts query definitions in ways that are easy
for perl programmers, while still allowing access to underlying SQL jazz,
and (b) reduces the work of performing a query to one statement, returning
the results in perl structure.
This is useful enough as a programming short hand, but is it really a
"Database Abstraction Layer" or "Object Persistence System"? (Anyone care to
define the difference between those two things?)
I still see you using database specific code with the "LIMIT" section and
the way that you performed a join with "STRAIGHT_JOIN" is different than I
do in Oracle, so you are tied to using MySQL:
}} my $r_ary = $db_obj->sql_get_matched_rows_ary_ref
}} (
}} "tracker STRAIGHT_JOIN users",
}} [map {"users.$_"} @verbose_cols],
}} [],
}} ["WHERE tracker.username=users.username",
}} "ORDER BY users.username",
}} "LIMIT $offset,$hits"],
}} );
It seems what you have defined is a "SQL Shorthand Layer." Do people agree
with this assessment?
There has been some talk that the abstraction layer (whatever you call it)
shouldn't end up being a re-write of the SQL syntax:
Gunther Birznieks <gunther@extropia.com> wrote:
> The one thing I would say, is that those of you that have been burned by
> persistence layers are perhaps burned for a parallel reason people have
> been burned by writing their own templating system. They start off simple
> and then they try to accommodate complexities in an automatic way. The
best
> persistence layers for SQL that I Have worked with start out simple and
> STAY simple. If you need a complexity, you expose $dbh and then run with
it
> and document that anomaly.
>
> Following this rule, few of my programs have the equivalent of $dbh
exposed
> and those that do are the exception. This allows me to teach a new
> programmer the persistence layer in half a day and then that's it and the
> programs tend to be easier to maintain and write. It's really not that
> different from utility functions that I see DBI programmers being used to.
> It's just an argument of where you place this code in the program.
Do these arguments fit here?
(NOT trying to start a fight!!! It may be just that Stas and Gunther want
*different* things in their abstraction layers.)
===
To: David Harris <dharris@drh.net>
From: Stas Bekman <stas@stason.org>
Subject: RE: dbi abstraction layer on perlmonks
Date: Sat, 4 Aug 2001 10:34:03 +0800 (SGT)
On Fri, 3 Aug 2001, David Harris wrote:
>
> Stas Bekman [mailto:stas@stason.org] wrote:
> > The mod_perl guide has an abstraction DBI layer module.
> > http://perl.apache.org/guide/databases.html#The_My_DB_module
> > I like it very much, but hey it was developed by me :)
> >
> > Note that I've improved the code since then, but the online version wasn't
> > updated yet. The concept didn't change though.
> >
> > If anybody likes the concept and want to take the ownership and release it
> > on CPAN, let me know.
>
> I looked at your My:DB library and this seems to me be a re-write of the SQL
> language and DBI that: (a) accepts query definitions in ways that are easy
> for perl programmers, while still allowing access to underlying SQL jazz,
> and (b) reduces the work of performing a query to one statement, returning
> the results in perl structure.
>
> This is useful enough as a programming short hand, but is it really a
> "Database Abstraction Layer" or "Object Persistence System"? (Anyone care to
> define the difference between those two things?)
I agree with you. My code is not an abstraction of the databases, but
remapping of SQL into Perl. This has simplified the development in many
ways, and allowed to change the underlying layer to adjust to the new
database if needed without changing the code.
I've attached a newer and much better version of the code. Notice that the
new name is SemiDBI :)
> I still see you using database specific code with the "LIMIT" section and
> the way that you performed a join with "STRAIGHT_JOIN" is different than I
> do in Oracle, so you are tied to using MySQL:
>
> }} my $r_ary = $db_obj->sql_get_matched_rows_ary_ref
> }} (
> }} "tracker STRAIGHT_JOIN users",
> }} [map {"users.$_"} @verbose_cols],
> }} [],
> }} ["WHERE tracker.username=users.username",
> }} "ORDER BY users.username",
> }} "LIMIT $offset,$hits"],
> }} );
Absolutely. This module wasn't designed top down, but rather down to top.
It was written as I needed new functions. And things like JOIN are
absolutely a hack and not really supported by the library itself. If you
like the code, feel free to come up with a nice way to do it without tying
the code to a specific DB.
The cool thing about my code is various tracing and debugging features,
which I can turn on and off for the whole code. Which makes the debugging
so much easier.
> It seems what you have defined is a "SQL Shorthand Layer." Do people agree
> with this assessment?
I agree.
> There has been some talk that the abstraction layer (whatever you call it)
> shouldn't end up being a re-write of the SQL syntax:
Note that my code doesn't try to re-write SQL, but rather to remap it into
a Perl way.
===
To: "David Harris" <dharris@drh.net>, "Stas Bekman"
<stas@stason.org>,
From: Gunther Birznieks <gunther@extropia.com>
Subject: RE: dbi abstraction layer on perlmonks
Date: Sat, 04 Aug 2001 12:33:44 +0800
At 04:40 PM 8/3/2001 -0400, David Harris wrote:
>Stas Bekman [mailto:stas@stason.org] wrote:
> > The mod_perl guide has an abstraction DBI layer module.
> > http://perl.apache.org/guide/databases.html#The_My_DB_module
> > I like it very much, but hey it was developed by me :)
> >
> > Note that I've improved the code since then, but the online version wasn't
> > updated yet. The concept didn't change though.
> >
> > If anybody likes the concept and want to take the ownership and release it
> > on CPAN, let me know.
>
>I looked at your My:DB library and this seems to me be a re-write of the SQL
>language and DBI that: (a) accepts query definitions in ways that are easy
>for perl programmers, while still allowing access to underlying SQL jazz,
>and (b) reduces the work of performing a query to one statement, returning
>the results in perl structure.
>
>This is useful enough as a programming short hand, but is it really a
>"Database Abstraction Layer" or "Object Persistence System"? (Anyone care to
>define the difference between those two things?)
An Object Persistence System is a system that can take object attributes
and relationships and map them fairly automatically do a relational
database. So I might have an employee object whose methods are save,
retrieve, delete with all the get and set methods I require for accessing
attributes in that object or set of objects.
A Database Abstraction Layer tends to be a simpler way of accessing a
database without resorting to SQL. This is closer to what I tend to use. At
eXtropia we have a rich set of objects with an interface that we call
"DataSource", such that we can plug and play DataSource::DBI,
DataSource::File, DataSource::XML, DataSource::FileTree, DataSource::POP3,
DataSource::IMAP etc...
The reason we do this is that all our application ship using flat files by
default because our audience is the public domain community first as we are
an open source site. But we do need access to DBI databases efficiently and
across a wide range of databases, so we have an abstraction for this.
Also, SQL is a poor mechanism to access certain types of data efficiently
(flat files are horribly inefficient with SQL), so actually a simplied
higher level access language also allows significant performance
improvements. The DataSource concept we use is almost identical to
Microsoft's ADO concept. ADO is not an object persistence layer, it's just
a database abstraction.
There is also a 3rd category which I would term Database Utilities. I think
many of the people who marry their SQL to their business objects tend to
use some sort of Database Utility set to make generating where clauses and
the like much easier, but at the end of the day, it's still raw DBI calls.
Does this clarify it appropriately?
>I still see you using database specific code with the "LIMIT" section and
>the way that you performed a join with "STRAIGHT_JOIN" is different than I
>do in Oracle, so you are tied to using MySQL:
>
>}} my $r_ary = $db_obj->sql_get_matched_rows_ary_ref
>}} (
>}} "tracker STRAIGHT_JOIN users",
>}} [map {"users.$_"} @verbose_cols],
>}} [],
>}} ["WHERE tracker.username=users.username",
>}} "ORDER BY users.username",
>}} "LIMIT $offset,$hits"],
>}} );
>
>It seems what you have defined is a "SQL Shorthand Layer." Do people agree
>with this assessment?
>
>There has been some talk that the abstraction layer (whatever you call it)
>shouldn't end up being a re-write of the SQL syntax:
>
>Gunther Birznieks <gunther@extropia.com> wrote:
> > The one thing I would say, is that those of you that have been burned by
> > persistence layers are perhaps burned for a parallel reason people have
> > been burned by writing their own templating system. They start off simple
> > and then they try to accommodate complexities in an automatic way. The
>best
> > persistence layers for SQL that I Have worked with start out simple and
> > STAY simple. If you need a complexity, you expose $dbh and then run with
>it
> > and document that anomaly.
> >
> > Following this rule, few of my programs have the equivalent of $dbh
>exposed
> > and those that do are the exception. This allows me to teach a new
> > programmer the persistence layer in half a day and then that's it and the
> > programs tend to be easier to maintain and write. It's really not that
> > different from utility functions that I see DBI programmers being used to.
> > It's just an argument of where you place this code in the program.
>
>Do these arguments fit here?
No not entirely. That's why the thread was called OT, but for whatever
reason people keep renaming the f-in thread and taking off OT. Sigh.
>(NOT trying to start a fight!!! It may be just that Stas and Gunther want
>*different* things in their abstraction layers.)
Actually I have been looking at incorporating Stas' syntax (or something
similar) to what we use because I think it has some better efficiency in
the utility methods. Although our DBI layer is built to work on Sybase,
Oracle, mySQL, and PostGres quite interchangeably so perhaps it has some
differences.
As for fighting, well, Stas sits 4 desks down from mine in our office... So
I don't think you have to start a fight... We start our own all the time
usually because most of my own programming is in Java these days and I
think I almost started a war when I bought the new O'Reilly .Net and C#
books at the conference...
===