Thread: [Modeling-users] ModelMasons refactored
Status: Abandoned
Brought to you by:
sbigaret
Menu
▾
▴
modeling-users
|
From: Sebastien B. <sbi...@us...> - 2003-04-20 16:12:18
|
Ok, the refactor of ModelMasons/ModelMason.py and PyModelMason.py is
checked in.
The default behaviour has slightly changed:
- before: the building process stops if the target directory already
exists
- now: the generating process do not stop any more. Rather, it ignores
the files that already exists. The only files that are overwritten
are model_<modelName>.xml and model_<modelName>.py.
Please update the following files:
scripts/mdl_generate_python_scripts.py v1.3
ModelMasons/ModelMason.py v1.6
ModelMasons/PyModelMason.py v1.7
Next step on this will be to integrate the 'Base' generation-scheme,
as discussed earlier on the mailing-list (with a patch proposed by
soif).
I quickly checked that my models are correctly generated from python &
ZModeler, I'll appreciate if someone could double-check.
-- S=E9bastien.
|
|
From: Sebastien B. <sbi...@us...> - 2003-04-20 16:24:40
|
> Next step on this will be to integrate the 'Base' generation-scheme,
> as discussed earlier on the mailing-list (with a patch proposed by
> soif).
Ok, done. If you want to test, please update
scripts/mdl_generate_python_code.py
ModelMasons/ (whole directory)
The old generation scheme is still the default (we can change that for 0.=
9),
or with option -C (C for compact)
The new one is accessible w/ the -B option (B for base)
It generates <className>Base.py as well as <className>.py
As in the 'compact' scheme, files model_<modelName>.py and .xml are
overwritten. Additionally, '...Base' module are also overwritten.
(TBD Note: this should be documented within the script's --help)
Inheritance:
------------
The following inheritance hierarchy is generated for
StoreEmployees.Employee/Executive:
EmployeeBase <--- Employee <---- ExecutiveBase <---- Executive
=20=20
I applied the old and new schemes to StoreEmployees and AuthorBooks, with
success (tests OK). However, here again I'll appreciate if somebody
interested in the topic could test and double-check with his own project
(Brad, Soif?)
Regards,
-- S=E9bastien.
|
|
From: <so...@la...> - 2003-04-20 20:43:21
|
On Sun, Apr 20, 2003 at 06:24:35PM +0200, Sebastien Bigaret wrote:
>
> > Next step on this will be to integrate the 'Base' generation-scheme,
> > as discussed earlier on the mailing-list (with a patch proposed by
> > soif).
This is from my first tests. Little things that i don't really
like :
1) As you proposed in the last discussion about this my previous patch do
something like that:
mortal
|-- Objects
| |-- Article.py
| |-- Base
| | |-- ArticleBase.py
| | |-- FolderBase.py
| | |-- FolderBase.pyc
| | |-- RssFeedBase.py
| | |-- __init__.py
| | `-- __init__.pyc
| |-- Folder.py
| |-- Folder.pyc
| |-- RssFeed.py
| |-- __init__.py
| |-- model_Mortal.py
| |-- model_Mortal.xml
| `-- setup.py
`-- __init__.py
as my package name is mortal.Objects, you can see that Base class
are cleary separated from the class you work on.
2) I look at the code i generated:
==============================================
# Modeling Base Objects
from Base.FolderBase import FolderBase
class Folder(FolderBase):
"""
Folders are objects ...
"""
def __init__(self):
"Initializer"
FolderBase.__init__(self)
===============================================
This is from the CVS version
===============================================
from FolderBase import FolderBase
from Modeling.Validation import ValidationException
from mx.DateTime import DateTimeFrom
class Folder(FolderBase):
"""
Folders are objects ...
"""
def __init__(self):
"Initializer"
# Note: if you modify this method, it is a strong requirement that
# every parameter gets a default value, since the framework needs to be
# able to instanciate an object with no parameter at all.
FolderBase.__init__(self)
===============================================
--> from Modeling.Validation import ValidationException
--> from mx.DateTime import DateTimeFrom
twiced imported (in working and in base)
the __init__(self).. have a wrong comment isnt'it ?
this isn't a big trick
>
> Ok, done. If you want to test, please update
>
> scripts/mdl_generate_python_code.py
> ModelMasons/ (whole directory)
>
>
> The old generation scheme is still the default (we can change that for 0.9),
> or with option -C (C for compact)
It should be the defaut in ZModeling too ( I haven't checkout this)
> The new one is accessible w/ the -B option (B for base)
> It generates <className>Base.py as well as <className>.py
>
> As in the 'compact' scheme, files model_<modelName>.py and .xml are
> overwritten. Additionally, '...Base' module are also overwritten.
> (TBD Note: this should be documented within the script's --help)
This sound a good feature. Anyways i don't care about anything in
Base folder w/ my patch
>
> Inheritance:
>
> The following inheritance hierarchy is generated for
> StoreEmployees.Employee/Executive:
>
> EmployeeBase <--- Employee <---- ExecutiveBase <---- Executive
>
>
> I applied the old and new schemes to StoreEmployees and AuthorBooks, with
> success (tests OK). However, here again I'll appreciate if somebody
> interested in the topic could test and double-check with his own project
> (Brad, Soif?)
Hum I don't remember how my patch handle inheritance in fact . and i
don't have a working inheritance here ...
Anyways despite my comments the generated code (from the CVS version)
works fine here.
Thanks
|
|
From: Mario R. <ma...@ru...> - 2003-04-21 07:55:51
|
Just a minor comment, w.r.t. naming of the generated files/classes.
I feel that:
a) "Base" is probably not the best name extension to use, as it has
a well-known generic meaning, and in addition it says nothing about
the "volatility" of these generated files/classes. Better names would
be something like "Auto" or "Gen" or "mdl" or "pom" or "morfy" ...
b) It is unnecessarily repeated -- what is the point of naming all the
classes in the "Base" sub-package also with "Base"? Wouldn't it be
more convenient to name only the sub-package? E.g.
mortal
|-- Objects
| |-- Article.py
| |-- Auto
| | |-- Article.py
| | |-- Folder.py
| | |-- RssFeed.py
| | |-- __init__.py
| |-- Folder.py
| |-- RssFeed.py
| |-- __init__.py
| |-- model_Mortal.py
| |-- model_Mortal.xml
| `-- setup.py
`-- __init__.py
which implies the import statements in the "working: classes:
==============================================
# Modeling Automatically-generated Objects
import Auto
class Folder(Auto.Folder):
...
==============================================
Regards, mario
> On Sun, Apr 20, 2003 at 06:24:35PM +0200, Sebastien Bigaret wrote:
[snip]
> mortal
> |-- Objects
> | |-- Article.py
> | |-- Base
> | | |-- ArticleBase.py
> | | |-- FolderBase.py
> | | |-- FolderBase.pyc
> | | |-- RssFeedBase.py
> | | |-- __init__.py
> | | `-- __init__.pyc
> | |-- Folder.py
> | |-- Folder.pyc
> | |-- RssFeed.py
> | |-- __init__.py
> | |-- model_Mortal.py
> | |-- model_Mortal.xml
> | `-- setup.py
> `-- __init__.py
[snip]
>
> 2) I look at the code i generated:
> ==============================================
> # Modeling Base Objects
> from Base.FolderBase import FolderBase
>
>
> class Folder(FolderBase):
> """
> Folders are objects ...
> """
>
> def __init__(self):
> "Initializer"
> FolderBase.__init__(self)
> ===============================================
[snip]
|
|
From: Sebastien B. <sbi...@us...> - 2003-04-21 12:51:50
|
so...@la... wrote:
> On Sun, Apr 20, 2003 at 06:24:35PM +0200, Sebastien Bigaret wrote:
> >=20
> > > Next step on this will be to integrate the 'Base' generation-scheme,
> > > as discussed earlier on the mailing-list (with a patch proposed by
> > > soif).
>=20
>=20
> This is from my first tests. Little things that i don't really
> like :
>=20
> 1) As you proposed in the last discussion about this my previous patch do
> something like that:
>=20
> mortal
> |-- Objects
> | |-- Article.py
> | |-- Base
> | | |-- ArticleBase.py
> | | |-- FolderBase.py
> | | |-- FolderBase.pyc
> | | |-- RssFeedBase.py
> | | |-- __init__.py
> | | `-- __init__.pyc
> | |-- Folder.py
> | |-- Folder.pyc
> | |-- RssFeed.py
> | |-- __init__.py
> | |-- model_Mortal.py
> | |-- model_Mortal.xml
> | `-- setup.py
> `-- __init__.py
>=20
> as my package name is mortal.Objects, you can see that Base class
> are cleary separated from the class you work on.=20
Ok, seems reasonable.
Mario wrote:
> Just a minor comment, w.r.t. naming of the generated files/classes.
> I feel that:
>=20
> a) "Base" is probably not the best name extension to use, as it has
> a well-known generic meaning, and in addition it says nothing about
> the "volatility" of these generated files/classes. Better names would
> be something like "Auto" or "Gen" or "mdl" or "pom" or "morfy" ...
Reasonable too. What about 'Autogen'? Since we're going this way I guess
that models (xml/py) should be moved to that directory too, so that
everything that is overwritten when generating the code clearly falls in
the dedicated directory.
Mario> b) It is unnecessarily repeated -- what is the point of naming
Mario> all the classes in the "Base" sub-package also with "Base"?
Mario> Wouldn't it be more convenient to name only the sub-package? E.g.
[...]
No problem; since we forget about 'Base' as a package it's a nonsense to
keep it here.
Back to Soif:
[...]
> This is from the CVS version=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> from FolderBase import FolderBase
> from Modeling.Validation import ValidationException
> from mx.DateTime import DateTimeFrom
>=20
> class Folder(FolderBase):=20
> """
> Folders are objects ...
> """
>=20=20=20
> def __init__(self):
> "Initializer"
> # Note: if you modify this method, it is a strong requirement that
> # every parameter gets a default value, since the framework needs to =
be
> # able to instanciate an object with no parameter at all.
> FolderBase.__init__(self)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> --> from Modeling.Validation import ValidationException
> --> from mx.DateTime import DateTimeFrom
> twiced imported (in working and in base)=20
>=20
> the __init__(self).. have a wrong comment isnt'it ?=20
>=20=20=20=20
> this isn't a big trick=20
-> mxDateTime: okay, this should be only in the AutoGen's modules
-> Validation: in the other one (w/ examples of validation methods)
About the initializer/its comment: let me think a little about
this... Mario just posted a question in relation and I have to
double-check some behaviour in the framework before answering.
> >=20
> > Inheritance:
> >=20
> > The following inheritance hierarchy is generated for
> > StoreEmployees.Employee/Executive:
> >=20
> > EmployeeBase <--- Employee <---- ExecutiveBase <---- Executive
> >=20
> >=20=20=20
> > I applied the old and new schemes to StoreEmployees and AuthorBooks, =
with
> > success (tests OK). However, here again I'll appreciate if somebody
> > interested in the topic could test and double-check with his own proj=
ect
> > (Brad, Soif?)
>=20
> Hum I don't remember how my patch handle inheritance in fact . and i
> don't have a working inheritance here ...=20
There was a little pb in your patch since the ''base'' class was ignored
for an entity having a parent, no big deal.
If we're okay on the points raised here (apart from initializer) I'll
make the changes today.
-- S=E9bastien.
|
|
From: Jerome K. <Jer...@fi...> - 2003-04-21 13:02:49
|
On Mon, Apr 21, 2003 at 02:51:46PM +0200, Sebastien Bigaret wrote: >=20 > > as my package name is mortal.Objects, you can see that Base class > > are cleary separated from the class you work on.=20 >=20 > Ok, seems reasonable. Yeah :)=20 =20 > Mario wrote: > > Just a minor comment, w.r.t. naming of the generated files/classes. > > I feel that: > >=20 > > a) "Base" is probably not the best name extension to use, as it has > > a well-known generic meaning, and in addition it says nothing about > > the "volatility" of these generated files/classes. Better names would > > be something like "Auto" or "Gen" or "mdl" or "pom" or "morfy" ... >=20 > Reasonable too. What about 'Autogen'? Since we're going this way I gues= s > that models (xml/py) should be moved to that directory too, so that > everything that is overwritten when generating the code clearly falls i= n > the dedicated directory. Hum I want to maintain a reference to the fact that this came from the=20 modeling. Cause i use some ORB here and it generate a lot of code too=20 so 'Autogen' hurt me a little . (same in glade too)=20 I prefer the previous one 'Mdl' or something else.=20 =20 > Mario> b) It is unnecessarily repeated -- what is the point of naming > Mario> all the classes in the "Base" sub-package also with "Base"? > Mario> Wouldn't it be more convenient to name only the sub-package? E.g= . > [...] >=20 > No problem; since we forget about 'Base' as a package it's a nonsense t= o > keep it here. Hum i'm not really clear about this, but i think this can generated namespace colision . mainly in the 'working' module=20 |
|
From: Mario R. <ma...@ru...> - 2003-04-21 14:37:50
|
On lundi, avr 21, 2003, at 15:02 Europe/Amsterdam, Jerome Kerdreux
wrote:
> On Mon, Apr 21, 2003 at 02:51:46PM +0200, Sebastien Bigaret wrote:
>
>> Mario wrote:
>>> Just a minor comment, w.r.t. naming of the generated files/classes.
>>> I feel that:
>>>
>>> a) "Base" is probably not the best name extension to use, as it has
>>> a well-known generic meaning, and in addition it says nothing about
>>> the "volatility" of these generated files/classes. Better names would
>>> be something like "Auto" or "Gen" or "mdl" or "pom" or "morfy" ...
>>
>> Reasonable too. What about 'Autogen'? Since we're going this way I
>> guess
>> that models (xml/py) should be moved to that directory too, so that
>> everything that is overwritten when generating the code clearly falls
>> in
>> the dedicated directory.
>
> Hum I want to maintain a reference to the fact that this came from the
> modeling. Cause i use some ORB here and it generate a lot of code too
> so 'Autogen' hurt me a little . (same in glade too)
> I prefer the previous one 'Mdl' or something else.
Don't understand. Why does AutoGen give you a problem and Base
does not, as far as other 3rd party generated code goes ?
>> Mario> b) It is unnecessarily repeated -- what is the point of naming
>> Mario> all the classes in the "Base" sub-package also with "Base"?
>> Mario> Wouldn't it be more convenient to name only the sub-package?
>> E.g.
>> [...]
>>
>> No problem; since we forget about 'Base' as a package it's a nonsense
>> to
>> keep it here.
>
>
> Hum i'm not really clear about this, but i think this can generated
> namespace colision . mainly in the 'working' module
Well, it is true if you import it directly into the local namespace.
However, i fell it is a lot of clutter to keep repeating the prefix (or
postfix)
for each file. What is the point of having a namespace if not to avoid
having to do such things?
Besides, instead of:
import AutoGen
class Folder(AutoGen.Folder):
...
no-one will ever stop you from doing:
from AutoGen import Folder as FolderBase
class Folder(FolderBase):
...
Except yourself, of course ;)
Cheers, mario
|
|
From: Sebastien B. <sbi...@us...> - 2003-04-21 14:58:14
|
Mario Ruggier <ma...@ru...> wrote: > On lundi, avr 21, 2003, at 15:02 Europe/Amsterdam, Jerome Kerdreux wrote: >=20 > > On Mon, Apr 21, 2003 at 02:51:46PM +0200, Sebastien Bigaret wrote: > > > >> Mario wrote: > >>> Just a minor comment, w.r.t. naming of the generated files/classes. > >>> I feel that: > >>> > >>> a) "Base" is probably not the best name extension to use, as it has > >>> a well-known generic meaning, and in addition it says nothing about > >>> the "volatility" of these generated files/classes. Better names would > >>> be something like "Auto" or "Gen" or "mdl" or "pom" or "morfy" ... > >> > >> Reasonable too. What about 'Autogen'? Since we're going this way I gue= ss > >> that models (xml/py) should be moved to that directory too, so that > >> everything that is overwritten when generating the code clearly falls = in > >> the dedicated directory. > > > > Hum I want to maintain a reference to the fact that this came from the > > modeling. Cause i use some ORB here and it generate a lot of code too > > so 'Autogen' hurt me a little . (same in glade too) > > I prefer the previous one 'Mdl' or something else. >=20 > Don't understand. Why does AutoGen give you a problem and Base > does not, as far as other 3rd party generated code goes ? I guess Soif prefers to have the AutoGen directory named after the framework which generated it, since he uses other tools, such as glade, also generating code. I personally do not care: I consider the two generation scheme as example on how things can be done. It's no big deal, however, I guess we can choose 'MDL'. > >> Mario> b) It is unnecessarily repeated -- what is the point of naming > >> Mario> all the classes in the "Base" sub-package also with "Base"? > >> Mario> Wouldn't it be more convenient to name only the sub-package? E.= g. > >> [...] > >> > >> No problem; since we forget about 'Base' as a package it's a nonsense = to > >> keep it here. > > > > > > Hum i'm not really clear about this, but i think this can generated > > namespace colision . mainly in the 'working' module >=20 > Well, it is true if you import it directly into the local namespace. > However, i fell it is a lot of clutter to keep repeating the prefix (or > postfix) > for each file. What is the point of having a namespace if not to avoid > having to do such things? > [...] I agree, I feel like we'll keep it as-is; I too can't see any good reason why a collision in the namespace could reasonably happen. -- S=E9bastien. |
|
From: Sebastien B. <sbi...@us...> - 2003-04-21 16:42:42
|
Ok, I think we have a problem here w/ the 'base' generation
scheme. Consider you modify the StoreEmployees model so that the classes
Employee, Executive and SalesClerk are in the same module
'Employees'. This would generate:
StoreEmployees
|-- Address.py
|-- Employees.py (Employee+Executive+SalesClerk)
|-- Mark.py
|-- MDL
| |-- Address.py
| |-- Employees.py (Employee+Executive+SalesClerk)
| |-- Mark.py
| |-- Store.py
| |-- __init__.py
| |-- model_StoreEmployees.py
| `-- model_StoreEmployees.xml
|-- Store.py
|-- __init__.py
`-- setup.py
Remember that the inheritance goes like this:
MDL.Employee <--- Employee <---- MDL.Executive <---- Executive
1. in MDL.__init__, we HAVE to 'import Employees' if we want to be able
to write in StoreEmployees.Employees:
class Employee(MDL.Employees.Employee):
"..."
2. in MDL.Employees we have to write something like this:
from StoreEmployees.Employees import Employee as EmployeeConcrete
class Employee(CustomObject):
"..."
class Employee(EmployeeConcrete):
"..."
class SalesClerk(EmployeeConcrete):
"..."
The problem? It creates an import loop between packages 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?
-- S=E9bastien.
|
|
From: Sebastien B. <sbi...@us...> - 2003-04-21 23:10:29
|
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 classes
> Employee, Executive and SalesClerk are in the same module
> 'Employees'. This would generate:
[snip]
> The problem? It creates an import loop between packages 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).
>=20
> 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?
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.
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?
Happy testing!
-- S=E9bastien.
|
|
From: Mario R. <ma...@ru...> - 2003-04-22 10:15:48
|
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. |
|
From: Sebastien B. <sbi...@us...> - 2003-04-22 12:08:01
|
Mario Ruggier <ma...@ru...> writes:
> Some minor comments, from tests here using the scripts:
>=20
> mdl_validate -v
> - the -v switch is not listed in the usage info printed by the script's -h
Fixed on the cvs main trunk. I also changed a little the options: now
'-w' discards warnings and info., and 'q' discards info. '-Q' is for
*really* quiet.
> mdl_generate_python_code.py -B
> - it looks like second time generation does not overwrite anything in
> the MDL directory. It should?
I can't reproduce that, see e.g.:
mdl_generate_python_code.py -B ./model_StoreEmployees.xml2
Creating directory ./StoreEmployees... no
File ./StoreEmployees/TODO.txt exists, skipping
File ./StoreEmployees/README.txt exists, skipping
File ./StoreEmployees/VERSION.txt exists, skipping
File ./StoreEmployees/INSTALL.txt exists, skipping
File ./StoreEmployees/DEPENDENCIES.txt exists, skipping
File ./StoreEmployees/__init__.py exists, skipping
File ./StoreEmployees/setup.py exists, skipping
Creating directory ./StoreEmployees/MDL... no
--> Generating ./StoreEmployees/MDL/__init__.py... done
Generating ./StoreEmployees/MDL/model_StoreEmployees.xml... done
Generating ./StoreEmployees/MDL/model_StoreEmployees.py... done
File ./StoreEmployees/Address.py exists, skipping
--> Generating ./StoreEmployees/MDL/Address.py... done
File ./StoreEmployees/Store.py exists, skipping
--> Generating ./StoreEmployees/MDL/Store.py... done
File ./StoreEmployees/Employees.py exists, skipping
--> Generating ./StoreEmployees/MDL/Employees.py... done
File ./StoreEmployees/Mark.py exists, skipping
--> Generating ./StoreEmployees/MDL/Mark.py... done
File ./StoreEmployees/Employee.py exists, skipping
--> Generating ./StoreEmployees/MDL/Employee.py... done
> - 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...
I understand, however in that case I recommend moving or destroying the
whole package or some files. I was forced to add this option earlier
(but didn't like it) because it wasn't possible to say in a generation
scheme which files should be overwritten; now that that's clear I prefer
that the user handles this.
> 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?
Not sure what you mean here:
$ mdl_generate_DB_schema.py -C -v \=20
> --admin-dsn=3D"localhost:template1:postgres:" ./model_StoreEmployees.xml
does not try any drop statements. Could you be more precise on which
situation(s) it annoys you?
> > 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?
>=20
> My vote is clear.
:)
-- S=E9bastien.
|
|
From: Mario R. <ma...@ru...> - 2003-04-22 13:30:43
|
On mardi, avr 22, 2003, at 14:07 Europe/Amsterdam, Sebastien Bigaret=20 wrote: > > Mario Ruggier <ma...@ru...> writes: >> 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=20 >> script's -h > > Fixed on the cvs main trunk. I also changed a little the options: now > '-w' discards warnings and info., and 'q' discards info. '-Q' is for > *really* quiet. OK. >> mdl_generate_python_code.py -B >> - it looks like second time generation does not overwrite anything in >> the MDL directory. It should? > > I can't reproduce that, see e.g.: Ooops, sorry my misreading of the log output ;-\ [snip] >> - 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... > > I understand, however in that case I recommend moving or destroying = the > whole package or some files. I was forced to add this option earlier > (but didn't like it) because it wasn't possible to say in a generation > scheme which files should be overwritten; now that that's clear I=20 > prefer > that the user handles this. OK, fair enough. > >> mdl_generate_DB_schema.py >> - when creating a table the first time around, all DROP statements=20 >> fail, >> and execution stops unless the -i switch is used. Shouldn't DROP of >> non-existant stuff not be treated like an error? > > Not sure what you mean here: > > $ mdl_generate_DB_schema.py -C -v \ >> --admin-dsn=3D"localhost:template1:postgres:" = ./model_StoreEmployees.xml > > does not try any drop statements. Could you be more precise on which > situation(s) it annoys you? mdl_generate_DB_schema.py -v -A model.xml Sorry, I was just being too lazy, and wanted to execute the same command whether it is the first time creating the table, or early interations=20 of the model (requiring frequent regeneration). Hadn't "registered" the -C switch... >>> 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. > > :) > > -- S=E9bastien. |
|
From: Sebastien B. <sbi...@us...> - 2003-04-22 17:14:20
|
Mario Ruggier <ma...@ru...> writes:
> >> mdl_generate_DB_schema.py
> >> - when creating a table the first time around, all DROP statements fai=
l,
> >> and execution stops unless the -i switch is used. Shouldn't DROP of
> >> non-existant stuff not be treated like an error?
> >
> > Not sure what you mean here:
> >
> > $ mdl_generate_DB_schema.py -C -v \
> >> --admin-dsn=3D"localhost:template1:postgres:" ./model_StoreEmployees.x=
ml
> >
> > does not try any drop statements. Could you be more precise on which
> > situation(s) it annoys you?
>=20
> mdl_generate_DB_schema.py -v -A model.xml
>=20
> Sorry, I was just being too lazy, and wanted to execute the same command
> whether it is the first time creating the table, or early interations of =
the
> model
> (requiring frequent regeneration). Hadn't "registered" the -C switch...
If you *really* want to be lazy, you'll probably find '-R -i' handy :)=20
BTW '-A' does not create the database, but with an existing database
'-A --ignore-errors' will ignore the initial & failing DROP TABLE.
Related to the topic: I just committed a slight change in
AbstractDBAPI2AdaptorLayer.AbstractDBAPI2Adaptor which apparently
solves a annoying pb. w/ postgresql (and maybe mysql as well), where
the creation of the db can fail when tried just after a 'DROP DB';
postgresql error is then:
ERROR: CREATE DATABASE: source database "template1" is being accessed by
other users
Obviously this is the case in mdl_generate_DB_schema with option -R.
-- S=E9bastien.
|
|
From: Mario R. <ma...@ru...> - 2003-04-25 00:11:00
|
On mardi, avr 22, 2003, at 15:15 Europe/Amsterdam, Mario Ruggier wrote: > On mardi, avr 22, 2003, at 14:07 Europe/Amsterdam, Sebastien Bigaret > wrote: >> Mario Ruggier <ma...@ru...> writes: [snip] >>>> BTW: Mario proposed that the generated class initializer could be: >>>>> def __init__(self,att1=None,att2=None): >>>> instead of >>>>> def __init__(self): >>>> >>>> Are we ok we go for it? A propos de previous post on KeyValueCoding names -- this proposition lacks a minor thing, and that is inside the __init__ body, the attribute values should be set using KeyValueCoding, not to bypass any custom code in the get/set methods for each attribute. Additional proposal ;) How about adding __slots__ to all custom objects? It seems to me that this is exactly the kind of usage that this was intended for, and will reduce memory usage for cases of *many* instances of custom objects. Works only for 2.2, but if present should not affect 2.1 instances in any way. mario |
|
From: Sebastien B. <sbi...@us...> - 2003-04-25 10:17:31
|
Mario Ruggier <ma...@ru...> writes:
> On mardi, avr 22, 2003, at 15:15 Europe/Amsterdam, Mario Ruggier wrote:
> > On mardi, avr 22, 2003, at 14:07 Europe/Amsterdam, Sebastien Bigaret wr=
ote:
> >> Mario Ruggier <ma...@ru...> writes:
>=20
> [snip]
>=20
> >>>> 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?
>=20
> A propos de previous post on KeyValueCoding names -- this proposition
> lacks a minor thing, and that is inside the __init__ body, the
> attribute values should be set using KeyValueCoding, not to bypass any
> custom code in the get/set methods for each attribute.
That's questionable. KVC mechanisms are handy, but
time-consuming. Moreover, I'd like to keep as little modeling-specific
things in the generated code as possible --for the moment being there
are Modeling.CustomObject in the inheritance tree, and
willRead()/willChange() methods [1].
I'd recommend self.setAtt1(att1) in __init__() rather than
self.takeValueForKey(att1, 'att1') in this case.
> Additional proposal ;)
> How about adding __slots__ to all custom objects?
> It seems to me that this is exactly the kind of usage that this was
> intended for, and will reduce memory usage for cases of *many*
> instances of custom objects. Works only for 2.2, but if present should
> not affect 2.1 instances in any way.
Could you be more specific? I can't see how slots reduce the memory
footprint.
More on slots: the framework cannot handle them out-of-the-box right
now, I can see the following problems:
a. when an EC records an object (either insert or fetch), it weakrefs
itself and assigns the weakref to the object (see
EC.recordObject()) --> this implies that CustomObject must be
turned into a new-style class in py2.2, defining __slots__ as well.
=20=20
b. Such an object cannot be weakly references, unless CustomObject
adds '__weakref__' in its slots.
=20=20
c. An object using slots has no __dict__
[See also: http://www.python.org/2.2.2/descrintro.html for a complete
discussion on csqs. of using slots]
a. and b. can be easily solved. However c. is more problematic; this is
an issue that should carefully examined (the impact is on KVC, mainly],
I'm not clear at all on this by now (I've never used new style classes
until now).
-- S=E9bastien.
[1] I'm currently working on a integrating the framework w/ the ZODB
framework. In this configuration willRead/willChange methods
disappears, and CustomObject inherits from ZODB's Persistent class.
I'll make a branch and an alpha release as soon as possible.
|
|
From: Mario R. <ma...@ru...> - 2003-04-25 10:49:12
|
On vendredi, avr 25, 2003, at 12:17 Europe/Amsterdam, Sebastien Bigaret=20=
wrote:
> Mario Ruggier <ma...@ru...> writes:
>> On mardi, avr 22, 2003, at 15:15 Europe/Amsterdam, Mario Ruggier=20
>> wrote:
>>> On mardi, avr 22, 2003, at 14:07 Europe/Amsterdam, Sebastien Bigaret=20=
>>> wrote:
>>>>>>> def __init__(self,att1=3DNone,att2=3DNone):
>>>>>> instead of
>>>>>>> def __init__(self):
>>>>>>
>>>>>> Are we ok we go for it?
>>
>> A propos de previous post on KeyValueCoding names -- this proposition
>> lacks a minor thing, and that is inside the __init__ body, the
>> attribute values should be set using KeyValueCoding, not to bypass =
any
>> custom code in the get/set methods for each attribute.
>
> That's questionable. KVC mechanisms are handy, but
> time-consuming. Moreover, I'd like to keep as little modeling-specific
> things in the generated code as possible --for the moment being there
> are Modeling.CustomObject in the inheritance tree, and
> willRead()/willChange() methods [1].
>
> I'd recommend self.setAtt1(att1) in __init__() rather than
> self.takeValueForKey(att1, 'att1') in this case.
Yes, you are right ;)
Since last night, i've rethought my little proposal, and I would
now be against it because of (a) if it is done this way, custom property
logic should not be bypassed in my opinion, and (b) if a KVC loop
is to be performed each time any CustomObj is initialised, the
performance price is too high.
But, how about this little compromise, as a utility function that
can be used only when needed:
def updateCustomObject(co,**kwargs):
for k in kwargs.keys():
co.setValueForKey(kwargs[k],k)
return co
It receives an instance =3D=3D>> can be used on new objects
(instantiated on the call) as well as existing instances.
>> Additional proposal ;)
>> How about adding __slots__ to all custom objects?
>> It seems to me that this is exactly the kind of usage that this was
>> intended for, and will reduce memory usage for cases of *many*
>> instances of custom objects. Works only for 2.2, but if present =
should
>> not affect 2.1 instances in any way.
>
> Could you be more specific? I can't see how slots reduce the memory
> footprint.
>
> More on slots: the framework cannot handle them out-of-the-box right
> now, I can see the following problems:
>
> a. when an EC records an object (either insert or fetch), it =
weakrefs
> itself and assigns the weakref to the object (see
> EC.recordObject()) --> this implies that CustomObject must be
> turned into a new-style class in py2.2, defining __slots__ as=20
> well.
>
> b. Such an object cannot be weakly references, unless CustomObject
> adds '__weakref__' in its slots.
>
> c. An object using slots has no __dict__
>
> [See also: http://www.python.org/2.2.2/descrintro.html for a complete
> discussion on csqs. of using slots]
>
> a. and b. can be easily solved. However c. is more problematic; this =
is
> an issue that should carefully examined (the impact is on KVC, =
mainly],
> I'm not clear at all on this by now (I've never used new style classes
> until now).
You are right, again ;)
I had not realised that __slots__ implied also these other things.
So this can be put on hold, for possible future consideration.
> -- S=E9bastien.
>
>
> [1] I'm currently working on a integrating the framework w/ the ZODB
> framework. In this configuration willRead/willChange methods
> disappears, and CustomObject inherits from ZODB's Persistent =
class.
> I'll make a branch and an alpha release as soon as possible.
Any implications for those not using ZODB?
mario
|
|
From: Sebastien B. <sbi...@us...> - 2003-04-25 11:25:45
|
Mario Ruggier <ma...@ru...> writes:
> >> A propos de previous post on KeyValueCoding names -- this proposition
> >> lacks a minor thing, and that is inside the __init__ body, the
> >> attribute values should be set using KeyValueCoding, not to bypass any
> >> custom code in the get/set methods for each attribute.
> >
> > That's questionable. KVC mechanisms are handy, but
> > time-consuming. Moreover, I'd like to keep as little modeling-specific
> > things in the generated code as possible --for the moment being there
> > are Modeling.CustomObject in the inheritance tree, and
> > willRead()/willChange() methods [1].
> >
> > I'd recommend self.setAtt1(att1) in __init__() rather than
> > self.takeValueForKey(att1, 'att1') in this case.
>=20
> Yes, you are right ;)
>=20
> Since last night, i've rethought my little proposal, and I would
> now be against it because of (a) if it is done this way, custom property
> logic should not be bypassed in my opinion, and (b) if a KVC loop
> is to be performed each time any CustomObj is initialised, the
> performance price is too high.
>=20
> But, how about this little compromise, as a utility function that
> can be used only when needed:
>=20
> def updateCustomObject(co,**kwargs):
> for k in kwargs.keys():
> co.setValueForKey(kwargs[k],k)
> return co
>=20
> It receives an instance =3D=3D>> can be used on new objects
> (instantiated on the call) as well as existing instances.
No problem w/ this. We just have to decide where it should be put! (module
CustomObject?)
[snip]
> I had not realised that __slots__ implied also these other things.
> So this can be put on hold, for possible future consideration.
BTW if someone on this list uses new-style classes and slots regularly plea=
se
email me privately, I have some questions about it --I'll summarize the
situation here afterwards.
> > [1] I'm currently working on a integrating the framework w/ the ZODB
> > framework. In this configuration willRead/willChange methods
> > disappears, and CustomObject inherits from ZODB's Persistent class.
> > I'll make a branch and an alpha release as soon as possible.
>=20
> Any implications for those not using ZODB?
Not in a near future, no need to worry. The goals underneath are:
- use ZODB.Persistent, because of the (C) extension class is *much* faster =
wrt
detecting that an object has changed (additionally, it make it possible to
transparently detect this, no willChange() needed anymore),
- bind the framework (esp. the EC fonctionalities) to the ZODB's transaction
machinery.
After release, the two versions will be maintained in parallel, and as far
as I'm concerned the current version won't be deprecated unless we reach =
the
point where noone uses it!
I'll make all this clearer in the long-term planning that Soif requested =
and
that I'll try to submit here soon.
Cheers,
-- S=E9bastien.
|
|
From: Sebastien B. <sbi...@us...> - 2003-05-16 11:44:53
|
Hi all,
I wrote:
> [...]
> 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.
>=20
> This constraint is not implemented yet.
>=20
> To retrieve the branch: in directory ModelMasons, directly type:
>=20
> $ cvs update -r brch-0_9pre6-1-ModelMasons_base_generation_scheme
>=20
>=20
> 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.
The constraint for 'base' generation scheme is now implemented in the
branch.
If nobody has more comments/requests/critics on this, this will be
integrated into the main trunk today or tomorrow and the brch will be
closed.
> BTW: Mario proposed that the generated class initializer could be:
> > def __init__(self,att1=3DNone,att2=3DNone):
> instead of
> > def __init__(self):
>=20
> Are we ok we go for it?
I'm too lazy to change this now; Mario also posted an alternate:
> But, how about this little compromise, as a utility function that
> can be used only when needed:
>=20
> def updateCustomObject(co,**kwargs):
> for k in kwargs.keys():
> co.setValueForKey(kwargs[k],k)
> return co
-> still needs to be done. Maybe this can be a FAQ entry in the
meantime.
-- S=E9bastien.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X