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 <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
