Discussion:
[Modeling-users] Database adaptors?
Federico Heinz
2004-03-02 21:23:04 UTC
Permalink
We're in contact with a prospective Modeling user. For reasons I'd
rather not go into (my doctor is worried about my blood pressure), these
people are likely to want to use it with DB2, for which no adaptor layer
is available yet.

This would be a nice opportunity for us to contribute said adaptor layer
to Modeling. I've taken a brief look at the available layers, and they
all seem pretty short and straightforward. Before attempting a go at it,
though, I'd like to ask the people who have written the other adaptors
whether there are any pitfalls to avoid, and what a reasonable time
estimate for writing the adaptor would be.

Fede
--
GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key BD02C6E0
Key Fingerprint: 04F4 08C5 14B7 2C3D DB21 ACF8 6CF5 0B0C BD02 C6E0
Sebastien Bigaret
2004-03-03 05:36:02 UTC
Permalink
Hi Fede,
Post by Federico Heinz
We're in contact with a prospective Modeling user. For reasons I'd
rather not go into (my doctor is worried about my blood pressure), these
people are likely to want to use it with DB2, for which no adaptor layer
is available yet.
This would be a nice opportunity for us to contribute said adaptor layer
to Modeling. I've taken a brief look at the available layers, and they
all seem pretty short and straightforward. Before attempting a go at it,
though, I'd like to ask the people who have written the other adaptors
whether there are any pitfalls to avoid
I can speak for the people who have written the other adaptors ;)

Yes, as you already observed it, writing a db adaptor is not really a
problem given that the python adaptor exists, and that the db does not
show too much differences wrt the SQL standards. As an example, I can
cite mysql, whose earlier version did not accept INNER JOINS, or Oracle
who requires a special statement to handle dates as expected.

Now the best (and/or quicker) way to write a new adaptor is to derive
it from an existing one --and, of course, to use the 3 scripts
test_EC_Global.py, test_Global_Inheritance.py and
test_EC_ParentChild.py to test it. Integration of a new adaptor in
these scripts should not be a problem: add an argument to '-d', and
write a new configuration file, say, DB2.cfg.

Last and to be complete, as you probably already noticed when looking at
other adaptors, the AbstractDBAPI2Adaptor layer implements all common
things needed by concrete adaptors relying on a DB-API 2.0 compliant
python adaptor.
Post by Federico Heinz
[asking about] what a reasonable time
estimate for writing the adaptor would be.
I'd say one to two days if you're already familiar with the db and the
corresponding python adaptor.

I'd be really pleased if you could find some time to develop a new
adaptor, and would happily integrate it into the framework! And, of
course, I'll be there if you need more details during the
dev. effort... to help you keep your blood pressure between reasonable
values ;)

BTW, we could also take this opportunity to start writing a draft of a short
document on "how to derive a new adaptor".

-- Sébastien.

Loading...