On 2/23/06 6:23 PM, Ron Savage wrote:
> o Rose::DB::Pg calls DateTime::Infinite::Past etc, so shouldn't it 'use'
> DateTime?

Yeah, it should.  (Well, DateTime::Infinite actually.)  It gets away with
not calling it because it uses Rose::DB which uses Rose::DateTime::Util
which uses DateTime::Infinite :)  Anyway, I've made the change in CVS.

> o In t/test-lib.pl some connexions use post_connect_sql. Is there something
> appropriate for Oracle I can add in here? My preference would be:
> 
> alter session set nls_timestamp_format = 'YYYY-MM-DD HH24:MI:SS'
> 
> Anything else?

Anything is fine.  I'm basically just making sure that feature isn't broken
in a particular db driver.  In practice, it's all pretty redundant since the
code for executing stuff post-connect is currently inherited as-is by all
Rose::DB subclasses.

> o In Rose::DB, I'm assuming the class methods don't need to be re-done in
> Rose::DB::Oracle, so the next step is to work on the object methods, right?
>
> Or would it be better to work thru pg.t and implement equivalents for, say,
> supports_limit_with_offset(), validate_timestamp_keyword(), etc?

Well, there are two issues here.  One is the public API, which you can read
in the Rose::DB POD.  If Rose::DB::Oracle needs to do something different
than Rose::DB for any of those methods, then you need to override.  If not,
then just accept the inherited version.

The only possible exceptions are the parse/format methods which I'd rather
see in each db-specific class, even if they do happen to match up with the
"generic" stub methods in Rose::DB.  I think that'd just be easier to
maintain and understand.

The second issue is all the undocumented stuff lurking in the Rose::DB:: Pg,
MySQL, SQLite, and Informix drivers.  These represent an ad-hoc,
ill-specified private interface between Rose::DB and Rose::DB::Object.  It's
done this way because I'm not sure exactly what kind of annoying little bits
of info Rose::DB::Object might need to do its work.  I didn't want to commit
to a public API and then learn that I'm "asking the wrong questions" about
each db.  (And true to form, I've changed that API many times.)

Although all of these methods exist in Rose::DB itself (if only a stubs),
that's mostly so I never have to check if a $db can() do one of them.  In
practice, most of them were added because one particular database does
something odd or needs special handling.  Inevitably, there will be more
such methods for Oracle.

So, which ones should you add to Rose::DB::Oracle?  Well, if one looks easy
to add and you understand what it's supposed to do, then go for it.  If
you're wondering what one is supposed to do, just ask on the list.
(Obviously these undocumented methods are, er, undocumented :)

The real fun will begin when we start to hash out how to get Oracle support
integrated into Rose::DB::Object.  In particular, the auto-primary-key stuff
should be an adventure.  But for now, just take your best shot at the
private APIs.  We'll likely have to tweak them as we cross over into
Rose::DB::Object land anyway.

-John







-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object

Reply via email to