Re: [Modeling-users] ModelMasons refactored

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

On mardi, avr 22, 2003, at 01:10 Europe/Amsterdam, Sebastien Bigaret=20
wrote:
>
> Sebastien Bigaret <sbi...@us...> writes:
>
>> Ok, I think we have a problem here w/ the 'base' generation
>> scheme. Consider you modify the StoreEmployees model so that the=20
>> classes
>> Employee, Executive and SalesClerk are in the same module
>> 'Employees'. This would generate:
> [snip]
>>   The problem? It creates an import loop between packages=20
>> StoreEmployees
>>   and StoreEmployees.MDL, and worse, another one between modules
>>   Employees and MDL.Employees (this problem remains even if we forget
>>   about the 'MDL' sub-directory and when all files are dropped within
>>   the same package).
>>
>>   If someone has a solution for this, please share!
>>
>>   I have the feeling that it is enough to state that a class and its
>>   subclass(es) should *not* share the same module when the 'base'
>>   generation scheme is involved. What do you think?

For now it will certainly be enough.
I do not have clear ideas how to best solve this at the moment...

> I've just finished a first proposal for this and committed it under =
the
> branch tagged brch-0_9pre6-1. It solves the problem as long as a class
> does not share the same module than one of its (direct or indirect)
> subclasses.
>
>   This constraint is not implemented yet.
>
> To retrieve the branch: in directory ModelMasons, directly type:
>
>     $ cvs update -r brch-0_9pre6-1-ModelMasons_base_generation_scheme
>
>
>   I successfully applied this on models AuthorBooks and =
StoreEmployees,
>   it would be cool if sb. could check that on his own projects. I also
>   did not pay a very close attention to the generated code (I just =
made
>   sure it works out-of-the-box wrt the tests), hence there can be
>   repetitions, useless portion of codes, etc. in the generated =
modules.

Some minor comments, from tests here using the scripts:

mdl_validate -v
- the -v switch is not listed in the usage info printed by the script's=20=

-h

mdl_generate_python_code.py -B
- it looks like second time generation does not overwrite anything in
the MDL directory. It should?
- the switch --overwrite-existing-files seems to have disappeared, but
to me it still makes sense to keep the option if you want a clean
generation, and want to throw away the "working" files...

mdl_generate_DB_schema.py
- when creating a table the first time around, all DROP statements fail,
and execution stops unless the -i switch is used. Shouldn't DROP of
non-existant stuff not be treated like an error?

Otherwise, I have found no other problem.


> BTW: Mario proposed that the generated class initializer could be:
>>   def __init__(self,att1=3DNone,att2=3DNone):
> instead of
>>   def __init__(self):
>
>   Are we ok we go for it?

My vote is clear.

mario


>     Happy testing!
>
> -- S=E9bastien.