On Sun, Nov 11, 2007 at 04:48:00PM -0200, Diego Pires Plentz wrote:
> Right Tom. The main problem is that hibernate propose is to be
> database independent, so, it isn't all databases that has a table
> with the list of all functions(and parameters/types to each
> function).
The "least common denominator" approach to database independence is
one strategy, but it pushes a lot of work into the users' hands.
The way things like Perl's DBI does it is that they have a baseline
set of features--the "least common denominator"--and then each
individual DBMS can have its own version-specific extensions which it
happens to be good at. For example, Oracle Spatial's APIs don't
really resemble PostGIS, but it would be good for Hibernate to access
both using methods tailored to each. Similar things apply to
full-text search capabilities, which are done radically differently
depending on which DBMS you're using.
Yes, it violates the assumption that you can just swap DBMSs from
under your application code, but I've never seen that assumption
hold for applications that actually use the RDBMS anyway.
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
