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
