Re: [Modeling-users] Oracle DB Adapter

[Sebastien B. <sbi...@us...>]

        Hi,

> I took a quick look at the MySQL and Postgresql adapters and I'm
> wondering if it would be possible to develop an Oracle adapeter un a
> resonable amount of time.
> The Postgresql adapter should generate SQL statements pretty close to=
 what
> we want in Oracle except for some types and some date formats.

Yes, it should be pretty straightforward. In fact I wrote the
AbstractDBAPI2AdaptorLayer after the whole postgresql layer was written,
just before deriving the mysql adaptor. The underlying goal was to
gather all the code for DB-APIv2-compliant python-adaptors in a single
place, letting only the details go in the specific layers (dsn, for exa=
mple).

> Are there any hidden glitches that I should be aware of ?

Hopefully there's no *hidden* glitches, or some docstrings should be
updated!

  First, you'll hopefully find all the necessary details for deriving
  AbstractDBAPI2AdaptorLayer in the docstrings ; if something is missing
  or unclear, please tell me (for example, AbstractAdaptorChannel fails
  to tell that the only method that must be overridden is
  primaryKeysForNewRowsWithEntity() --corrected in CVS).

Log msgs should be issued via the Modeling.logging.db_* methods
(db_trace, db_debug, etc.)

  If you need to add some specific types, you'll need to create a new
  Oracle9iSQLExpression and override valueTypeForExternalTypeMapping() =
as it
  is done for postgres or mysql (if you do, override
  Oracle9iAdaptor.defaultExpressionClass() as well). However for a first
  try the default (Modeling.SQLExpression) should be okay.

> except for some types and some date formats.

What do you mean by 'date formats' ?? For the moment being there's no
particular processing of dates. Within the framework we use mxDateTime,
and the conversion from/to the values in the DB is done by the
underlying python-adapters. But maybe I'm misunderstanding your point
here.


  Last, after writing, say, Oracle9iAdaptorLayer, you'll probably be ea=
ger
  to test it. The tests suite is ready for that: both tests
    test_EditingContext_Global.py and
    test_EditingContext_Global_Inheritance.py
=20=20
  take the '-d' option --given that you turn the line in their main()
  which says:

         if v not in ('Postgresql', 'MySQL'): usage(me, 1)

  into, e.g.:

         if v not in ('Postgresql', 'MySQL', 'Oracle9i'): usage(me, 1)


Well, this message looks like the beginning of an howto that should have
been already written ;)


    Anyway, if you find some time to derive the Oracle9iAdaptorLayer
    I'll be happy to help you with the details and it will be welcome in
    the DatabaseAdaptors!


> The design is pretty clean, really nice work here !

Thanks, but keep in mind that a good part of the architecture/design of
the whole framework is directly inspired/taken from the EOF's public
API, hence you can thank as well the former genious-nextstep-team who
did it!

        Regards,

-- S=E9bastien.