Re: [Modeling-users] few misc issues with sqlite adaptor

[Mario R. <ma...@ru...>]

On Samedi, ao=FB 9, 2003, at 13:49, Sebastien Bigaret wrote:
> Mario Ruggier <ma...@ru...> wrote:
>> On Jeudi, ao=FB 7, 2003, at 23:41, Sebastien Bigaret wrote:
>>> Mario Ruggier <ma...@ru...> wrote:
>>>> a few points, encountered when trying to make a pymodel,
>>>> running the mdl_* scripts, and using SQLite adaptor:
>>>>
>>>> 1. when running mdl_validate_model on a pymodel that
>>>> does not hard-wire an adaptorname:
>>>>
>>>>   * Warning(s):
>>>>     - Can't find concrete adaptor: can't check SQL types
>>>
>>> True, when it cannot be found they cannot be checked, so we warn the
>>> user.
>>
>> The point I was hinting ;) at is that in this case shouldn't =20
>> mdl_validate
>> select the adaptor pointed to by the "foremost" cfg file?
>
> I don't think I will support this. The connection dictionaries can be
> supplied within a model and/or in a file pointed by environment =20
> variable
> MDL_DB_CONNECTIONS_CFG. I think this is enough, and that this scheme
> shouldn't be complicated.

OK. Simplicity is always good.
Not to inadvertently use a central cfg for testing, I have a wrapper =20
for the mdl_*
scripts that always sets this variable to point to a specified =20
(defaults to samedir)
cfg.

[...]

>>>> 3. When running mdl_* utility scripts, the main cfg (pointed to by =20=

>>>> env
>>>> var MDL_DB_CONNECTIONS_CFG) is not taken into account.
>>>> Same goes for when an Adaptorname.cfg is made available in the
>>>> same directory as the pymodel.
>>>
>>> True, no matter where a .cfg is, if it's pointed to by =20
>>> MDL_DB_CONNECTIONS_CFG
>>> it should taken into account. This is a bug.
>>
>> Ehm, on closer looks I would have to take this back.
>> Generate_db does take this into account. Validate does
>> not... I have not determined of all the cases when it does or
>> does not though... I will file as "mdl_* scripts do not always take =20=

>> .cfg into
>> account",
>> or 785436.
>
> I'm sorry, I tried but cannot reproduce the bug here, I need more =
info.

Well, it is not clear to me:
- what may be in the cfg
- what should be in the cfg
- what may be in the command-line --admin-dsn
- what should be in the commandline --admin-dsn
- what optionally may be specified in the connectionDictionary in the =20=

model
Plus, if something is specified in more than one place which one takes =20=

precedence?

More precisely, here is a problem: if i do not specify the database in =20=

the
connDict of the model (I want to take out the connection dictionary =20
from the model,
in my opinion it is not where it should be), but do specify the db on =20=

the command
line with --admin-dsn, then mdl_gen_DB gives an error:

[0.9pre13]
% mdl_generate_DB_schema.py -C --admin-dsn localhost:db_m2m:dummy:dummy =20=

pym_m2m.py
Traceback (most recent call last):
   File "/usr/bin/mdl_generate_DB_schema.py", line 353, in ?
     status =3D main(sys.argv)
   File "/usr/bin/mdl_generate_DB_schema.py", line 340, in main
     dsn_db_name =3D model.connectionDictionary()['database']
KeyError: database

[0.9pre12]
% mdl_generate_DB_schema.py -C --admin-dsn localhost:db_m2m:dummy:dummy =20=

pym_m2m.py
Unable to open connexion w/ connectionDictionary=3D{'password': 'xxxx'}
Reason:
Traceback (most recent call last):
   File =20
"/usr/lib/python2.2/site-packages/Modeling/DatabaseAdaptors/=20
AbstractDBAPI2AdaptorLayer/AbstractDBAPI2AdaptorContext.py", line 219, =20=

in __openConnectionIfNecessary__
     self._adaptor.dbAPI_connectionDictionaryForConnect(cnxDict))
   File =20
"/usr/lib/python2.2/site-packages/Modeling/DatabaseAdaptors/=20
SQLiteAdaptorLayer/SQLiteAdaptor.py", line 102, in =20
dbAPI_connectionDictionaryForConnect
     return {'db': aModelConnectionDictionary['database']}
KeyError: database


Another problem: if i do not specify an adaptor in the pymodel, but i do
in the cfg pointed to by the environment, both mdl_validate and =20
mdl_generate_db
do not use the default adaptor specified in the cfg (tested with =20
0.9pre13).
Again, in my opinion such info should not be in the model -- a model, =20=

while
specifying db-specific things such as widths, and external types and so =20=

on,
should, in an ideal world, be able to be used with no modifications with
different SQL-respecting db servers. For example, I may want to develop
and test with sqlite, and then deploy on postrges, and it would be nice =20=

to
be able to do such things with no modifs on the models.


>> In addition to this problem, I feel it would be convenient (and safe) =
=20
>> to
>> make it such that either (a) commandline switch to specify a "test" =20=

>> cfg
>> whenever desired, and/or (b) use a local cfg if one is present (by =20=

>> which
>> name?).
>> This to prevent overwriting real db files while testing changed =20
>> models.
>
> I understand what you say, but as I said above I do not feel like
> complicating things here. It's impossible to foresee every possible
> situations where valuable data could be lost, and I have the feeling
> that trying to find more and more of these situations could lead to =
the
> wrong feeling that the script is safe, while complicating the =20
> everyday's
> life of developpers.
>
>   Right, mdl_generate_DB_schema.py should be handled with care, just
> like 'DROP' statements when connecting to a database, or shell's 'rm'
> when speaking of sqlite files... Does it make sense?

When I use rm I do not have a hidden value somewhere (env var that
points to another directory!) that underhandedly changes the obvious
face-value of the rm command being issued... so I am never surprised
at the results.

One may foresee an option to set which cfg file to use (but this is =20
easily
accomplished by a wrapper script that resets the envvar... so whether
this is warranted, not sure, your call).

The collection of mdl_* scripts sport an impressive variety of =20
options...
a another little one won't hurt surely ;-? (Hmmn, one should take a few
of the others out I think ;-!)

Thanks for all the other fixes, and the super-quick release afterwards!

Cheers, mario