modeling-users — For users: questions, support, announcements, etc.

Re: [Modeling-users] Re: attaching information to a relation

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

Mario Ruggier <ma...@ru...> wrote:
> >    In fact my previous post was about something like this:
> >
> >      Association('TypedAssoc','User',
> >        relations=3D['user','typed_assocs'],
> >        delete=3D['nullify','cascade'],
> >        keys=3D['FK_User_id','id']
> >      ),
> >      Association('TypedAssoc','Address',
> >        relations=3D['address','typed_assocs'],
> >        delete=3D['nullify','cascade'],
> >        keys=3D['FK_Address_id','id']
> >
> >    i.e.  User <----->> TypedAssoc <<-----> Address
>=20
> Hmmn, it seems I have switched the logic around.
> In this way the "user" and "address" relations show up as constraints
> on the TypedAssoc table.
>=20
> But, the problem with this is that if we re-use TypedAssoc
> also for a similar association between User and Organization
> (using this naming strategy) then there will be the ValueError
> mentioned above. Hence, using a  <source4target> naming
> scheme for these relations, and adding the ones for organization,
> we end up with a TypedAssoc definition of:
>=20
> CREATE TABLE TypedAssoc (
>    FK_USER_ID INTEGER ,
>    FK_ORGANIZATION_ID INTEGER ,
>    TYPE VARCHAR(30) ,
>    ID INTEGER NOT NULL PRIMARY KEY,
>    FK_ADDRESS_ID INTEGER ,
>    CONSTRAINT address4user FOREIGN KEY (FK_USER_ID) REFERENCES Address(ID=
),
>    CONSTRAINT organization4user FOREIGN KEY (FK_ORGANIZATION_ID) REFERENC=
ES
> Organization(ID),
>    CONSTRAINT user4address FOREIGN KEY (FK_ADDRESS_ID) REFERENCES User(ID=
),
>    CONSTRAINT user4organization FOREIGN KEY (FK_USER_ID) REFERENCES User(=
ID))
>=20
> Is this correct? This will rule out re-use of such a table...

I *think* this should work (even if untested, I've never gathered all
correlation tables into a single one. However I feel that some things
still needs to be fixed:

  1. there's a missing name for TYPE VARCHAR(30),

  2. constraints are not ok, I'd write:

    CONSTRAINT address4user FOREIGN KEY (FK_ADDRESS_ID) REFERENCES Address(=
ID),
    CONSTRAINT organization4user FOREIGN KEY (FK_ORGANIZATION_ID) REFERENCES
         Organization(ID),
    CONSTRAINT user4address FOREIGN KEY (FK_USER_ID) REFERENCES User(ID),
    CONSTRAINT user4organization FOREIGN KEY (FK_USER_ID) REFERENCES User(I=
D))

Last, the correlation tables has now 3 FKs: FK_USER_ID, FK_ADDRESS_ID
and FK_ORGANIZATION_ID. It should work, given that each row in
TypedAssoc only has two non null FKs.

> Question: why is the order in an association important?
> Or, why does switching the assoc around to this:
>=20
>       Association('User','TypedAssoc',
>         relations=3D['typed_assocs','user'],
>         delete=3D['cascade','nullify'],
>         keys=3D['id','FK_User_id']
>       ),
>=20
> give the following error:
>=20
> ValueError: Association(User,TypedAssoc): specifies a destination attribu=
te
> FK_User_id for entity TypedAssoc but this entity already has a PK named id

Handling many-to-many relationships is equivalent to working with
couples (user_id, address_id) that works together. That's what the
correlation tables does.

  If I re-read your previous model, you were trying to model something
  like:

     User <<-----> TypeAssoc <<----> Address


Important: remember that Association(E1, E2) means E1 <<----> E2

  ---> this does not model many-to-many, since one of the resulting
       rel. is then: User --> Address.


Last: the reason why you get the error above is that you declare a the
following relationship: User <<----> TypeAssoc, which is modeled with a
FK in User linked to a PK in TypeAssoc. Since TypeAssoc already has a pk
'id', trying to build this association makes the pymodel adds a pk named
'FK_User_id' in TypedAssoc --and since compound pk are not supported,
you get the error.=20

  But, independently to the support of compund PKs, your declaration of
  the associations is wrong (the order is wrong), this can be seen of
  the rels' names: the to-one is called 'typed_assocs' while the to-many
  is called 'user'.

The problem is that you were probably misled here by the names: since
you read 'typed_assocs' and 'user', you tend to think that associations
are resp. to-many and to-one, and since the cardinalities are implicit
here, that makes it harder to see the problem. In fact,=20

       Association('User','TypedAssoc',
         relations=3D['typed_assocs','user'],
         delete=3D['cascade','nullify'],
         keys=3D['id','FK_User_id']

is equivalent to (see Association's defaults):

       Association('User','TypedAssoc',
         relations=3D['typed_assocs','user'],
         multiplicity=3D[ [0,1], [0,None] ],
         delete=3D['cascade','nullify'],
         keys=3D['id','FK_User_id']

  and this version makes the pb appears clearly, doesn't it? ;)

-- S=E9bastien.

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

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

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.
>=20
> The point I was hinting ;) at is that in this case shouldn't 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 variable
MDL_DB_CONNECTIONS_CFG. I think this is enough, and that this scheme
shouldn't be complicated.

> >> 2. when running mdl_validate_model on a model that
> >> uses "text" as externalType (using SQLite adaptor):
[...]
> >
> > Should be fixed.
>=20
> Filed as bug 785432.

Fixed in CVS, see bug report and attached patch.

> >> 3. When running mdl_* utility scripts, the main cfg (pointed to by 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 MDL_DB_CONNECTIO=
NS_CFG
> > it should taken into account. This is a bug.
>=20
> 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 .cfg =
into
> account",
> or 785436.

I'm sorry, I tried but cannot reproduce the bug here, I need more info.

> In addition to this problem, I feel it would be convenient (and safe) to
> make it such that either (a) commandline switch to specify a "test" cfg
> whenever desired, and/or (b) use a local cfg if one is present (by which
> name?).
> This to prevent overwriting real db files while testing changed 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 everyday's
life of developpers.=20

  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?

> >> 4. When running mdl_generate_DB utility script, and specifying a
> >> --admin-dsn on the command line, and the db name in this dsn is
> >> different than the db name specified in the pymodel, then an empty
> >> file with the dsn_db name is created, and a proper sqlite db fis
> >> created in a file with the pymodel_db name.
> >
> > Ok, this could be checked by mdl_generate_DB.
>=20
> Bug 785434.

Fixed in CVS, and the corresponding patch is attached to the bug
report.

        Cheers,

-- S=E9bastien.

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

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

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?


>> 2. when running mdl_validate_model on a model that
>> uses "text" as externalType (using SQLite adaptor):
>>
>>   * Error(s):
>>     - Invalid SQL type: 'text' (valid for this adaptor: ['char',=20
>> 'date',
>> 'varchar', 'timestamp', 'time', 'int', 'integer', 'float', =
'numeric'])
>
> Should be fixed.

Filed as bug 785432.

>> 3. When running mdl_* utility scripts, the main cfg (pointed to by =
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.

In addition to this problem, I feel it would be convenient (and safe) to
make it such that either (a) commandline switch to specify a "test" 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 models.

>> 4. When running mdl_generate_DB utility script, and specifying a
>> --admin-dsn on the command line, and the db name in this dsn is
>> different than the db name specified in the pymodel, then an empty
>> file with the dsn_db name is created, and a proper sqlite db fis
>> created in a file with the pymodel_db name.
>
> Ok, this could be checked by mdl_generate_DB.

Bug 785434.

>   Could you add bug reports for each of these three items? I'll=20
> probably
>   look at them this week-end. And thanks for reporting!
>
> -- S=E9bastien.

mario

Re: [Modeling-users] Re: attaching information to a relation

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

On Jeudi, ao=FB 7, 2003, at 23:37, Sebastien Bigaret wrote:

>   I do not have much time by now, so this is a quick answer:
>
> Mario Ruggier <ma...@ru...> wrote:
>>> I have a question here: is it a good idea to re-use such
>>> assoc tables to relate in a many-2-many way any arbitrary
>>> pair of tables? An m2m relationship with a type seems to
>>> me a frequently occurring situation, and it seems like a lot
>>> of overhead to declare a dedicated assoc table per relation.
>>> As an example, consider:
>>>
> [model snipped]
>>> This, the same assoc table is used for the m2m relations
>>> between User<>Address and User<>Organization.
>>> Is this a good way?
>>
>> I should have played with the above case a little more, as
>> it will not work like this -- because this will attempt to create
>> two relations on the ManyToMany_Type (now TypedAssoc) table,
>> that are both named 'user'. The mdl_validate error given is:
>>
>> ValueError: Attempt to insert a relationship in entity TypedAssoc but=20=

>> a key
>> named 'user' is already registered.
>
> In fact this is not directly mdl_validate_model raising, this happens
> when loading a model. These constraints about namespaces are strictly
> enforced by Model (while ModelValidation, implementing the logic for
> mdl_validate, starts its verificatins after the model is loaded).

OK, thanks for the explanation.

>> However, if i change the name of the relation on the Assoc table
>> (e.g. following a convention such as source_target), then the
>> db is created ok. Thus the assocs will change to:
>>
>>    Association('User','TypedAssoc',
>>      relations=3D['organizations','user_organization'],
>>      delete=3D['cascade','nullify'],
>>      keys=3D['FK_Organization_id','id'],
>>    ),
>>    Association('Organization','TypedAssoc',
>>      relations=3D['users','organization_user'],
>>      delete=3D['deny','nullify'],
>>      keys=3D['FK_User_id','id'],
>>    ),
>>    Association('User','TypedAssoc',
>>      relations=3D['addresses','user_address'],
>>      delete=3D['cascade','nullify'],
>>      keys=3D['FK_Address_id','id']
>>    ),
>>    Association('Address','TypedAssoc',
>>      relations=3D['users','address_user'],
>>      delete=3D['deny','nullify'],
>>      keys=3D['FK_User_id','id']
>>    ),
>
> I don't have the time to examine your model --seems strange, and the
> delete rules too.

If you get time, ...  ;)
For the delete rules, my intention is to state that :
a) when deleting an assoc itself, just nullify the 2 relationships
between it and the User and Address rows.
b) when deleting a User, i also want to delete any assocs...
c) i only want to be able to delete an Address if no User is
using it... (several Users may be using the same address for
different reasons).

>    In fact my previous post was about something like this:
>
>      Association('TypedAssoc','User',
>        relations=3D['user','typed_assocs'],
>        delete=3D['nullify','cascade'],
>        keys=3D['FK_User_id','id']
>      ),
>      Association('TypedAssoc','Address',
>        relations=3D['address','typed_assocs'],
>        delete=3D['nullify','cascade'],
>        keys=3D['FK_Address_id','id']
>
>    i.e.  User <----->> TypedAssoc <<-----> Address

Hmmn, it seems I have switched the logic around.
In this way the "user" and "address" relations show up as constraints
on the TypedAssoc table.

But, the problem with this is that if we re-use TypedAssoc
also for a similar association between User and Organization
(using this naming strategy) then there will be the ValueError
mentioned above. Hence, using a  <source4target> naming
scheme for these relations, and adding the ones for organization,
we end up with a TypedAssoc definition of:

CREATE TABLE TypedAssoc (
   FK_USER_ID INTEGER ,
   FK_ORGANIZATION_ID INTEGER ,
   TYPE VARCHAR(30) ,
   ID INTEGER NOT NULL PRIMARY KEY,
   FK_ADDRESS_ID INTEGER ,
   CONSTRAINT address4user FOREIGN KEY (FK_USER_ID) REFERENCES=20
Address(ID),
   CONSTRAINT organization4user FOREIGN KEY (FK_ORGANIZATION_ID)=20
REFERENCES Organization(ID),
   CONSTRAINT user4address FOREIGN KEY (FK_ADDRESS_ID) REFERENCES=20
User(ID),
   CONSTRAINT user4organization FOREIGN KEY (FK_USER_ID) REFERENCES=20
User(ID))

Is this correct? This will rule out re-use of such a table...

Question: why is the order in an association important?
Or, why does switching the assoc around to this:

      Association('User','TypedAssoc',
        relations=3D['typed_assocs','user'],
        delete=3D['cascade','nullify'],
        keys=3D['id','FK_User_id']
      ),

give the following error:

ValueError: Association(User,TypedAssoc): specifies a destination=20
attribute FK_User_id for entity TypedAssoc but this entity already has=20=

a PK named id


>> However, I am surprised that in the schema dump for the
>> created sqlite database, none of these relation names
>> (user_address, etc) show up! How does he know about
>> them when re-creating the db from the schema dump
>> (which he seems to do just fine) ?
>
> The relations do not appear in the sql dump of tables --they do not
> exist, all the informations about the relationships is stored within
> foreign keys. However, when the databases support it, the framework=20
> adds
> integrity constraints to the db schema, whose names are the =
relations's
> name: (from model StoreEmployees)
>
>> mdl_generate_DB_schema.py -A -c=20
>> StoreEmployees/pymodel_StoreEmployees.py
> [...]
> ALTER TABLE ADDRESS ADD CONSTRAINT toEmployee
>   FOREIGN KEY (FK_EMPLOYEE_ID)     ^^^^^^^^^^
>   REFERENCES EMPLOYEE(ID)
>   INITIALLY DEFERRED
> [...]

OK, except that for SQLite, there's no support for ALTER ;)

> However the framework does not make any use of these constraints=20
> --since
> it already respects them at the object level. They are just put in the
> db by mdl_generated_DB_schema's '-F' option: "create foreign key
> constraints", this can be useful e.g. if you want to interact w/ the =
db
> with a raw sql adaptor without worrying about the integrity of your=20
> data
> since these constraints are also declared and enforced by the=20
> db-server.

Very good, thanks for the explanation.

mario

Re: [Modeling-users] test_generate_python_code.sh

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

Mario Ruggier <ma...@ru...> wrote:
> Hi, i notice that 0.9pre12 has a new test. When I run it (after running t=
he
> others), I get the terminal output below. What does "OK: Failed" mean ;-?
> Oh, and this one really takes a long time (minutes) to execute...

> OK:    Failed:  StoreEmployees / -B w/ xmlmodels/pymodel_StoreEmployees3.=
py

It means the test succeeds in that the tested script should fail, and
has failed, in this situation ;) Here we test that the situations for
which the '-B' option isn't supported are correctly detected.

NB: When one of these tests fails it write 'ERROR:' instead of
    'OK:'. The Success/Failure strings afterwards are what is expected
    for the test.

> ./test_generate_python_code.sh: testPackages/StoreEmployees/Employee.py: =
No
> such file or directory
    The other msgs about files 'Employee.py' can be ignored.

  And yes, they take some time: for each one, the package is generated,
  then the appropriate tests are run (either test_EC_Global or
  test_EC_Global_Inheritance).

-- S=E9bastien.

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

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

Mario Ruggier <ma...@ru...> wrote:
> a few points, encountered when trying to make a pymodel,
> running the mdl_* scripts, and using SQLite adaptor:
>=20
> 1. when running mdl_validate_model on a pymodel that
> does not hard-wire an adaptorname:
>=20
>   * 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.

> 2. when running mdl_validate_model on a model that
> uses "text" as externalType (using SQLite adaptor):
>=20
>   * Error(s):
>     - Invalid SQL type: 'text' (valid for this adaptor: ['char', 'date',
> 'varchar', 'timestamp', 'time', 'int', 'integer', 'float', 'numeric'])

Should be fixed.

> 3. When running mdl_* utility scripts, the main cfg (pointed to by 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 MDL_DB_CONNECTIONS_C=
FG
it should taken into account. This is a bug.

> 4. When running mdl_generate_DB utility script, and specifying a
> --admin-dsn on the command line, and the db name in this dsn is
> different than the db name specified in the pymodel, then an empty
> file with the dsn_db name is created, and a proper sqlite db fis
> created in a file with the pymodel_db name.

Ok, this could be checked by mdl_generate_DB.

  Could you add bug reports for each of these three items? I'll probably
  look at them this week-end. And thanks for reporting!

-- S=E9bastien.

Re: [Modeling-users] Re: attaching information to a relation

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

        Hi,

  I do not have much time by now, so this is a quick answer:

Mario Ruggier <ma...@ru...> wrote:
> > I have a question here: is it a good idea to re-use such
> > assoc tables to relate in a many-2-many way any arbitrary
> > pair of tables? An m2m relationship with a type seems to
> > me a frequently occurring situation, and it seems like a lot
> > of overhead to declare a dedicated assoc table per relation.
> > As an example, consider:
> >
[model snipped]
> > This, the same assoc table is used for the m2m relations
> > between User<>Address and User<>Organization.
> > Is this a good way?
>=20
> I should have played with the above case a little more, as
> it will not work like this -- because this will attempt to create
> two relations on the ManyToMany_Type (now TypedAssoc) table,
> that are both named 'user'. The mdl_validate error given is:
>=20
> ValueError: Attempt to insert a relationship in entity TypedAssoc but a k=
ey
> named 'user' is already registered.

In fact this is not directly mdl_validate_model raising, this happens
when loading a model. These constraints about namespaces are strictly
enforced by Model (while ModelValidation, implementing the logic for
mdl_validate, starts its verificatins after the model is loaded).

> However, if i change the name of the relation on the Assoc table
> (e.g. following a convention such as source_target), then the
> db is created ok. Thus the assocs will change to:
>=20
>    Association('User','TypedAssoc',
>      relations=3D['organizations','user_organization'],
>      delete=3D['cascade','nullify'],
>      keys=3D['FK_Organization_id','id'],
>    ),
>    Association('Organization','TypedAssoc',
>      relations=3D['users','organization_user'],
>      delete=3D['deny','nullify'],
>      keys=3D['FK_User_id','id'],
>    ),
>    Association('User','TypedAssoc',
>      relations=3D['addresses','user_address'],
>      delete=3D['cascade','nullify'],
>      keys=3D['FK_Address_id','id']
>    ),
>    Association('Address','TypedAssoc',
>      relations=3D['users','address_user'],
>      delete=3D['deny','nullify'],
>      keys=3D['FK_User_id','id']
>    ),

I don't have the time to examine your model --seems strange, and the
delete rules too.

   In fact my previous post was about something like this:

     Association('TypedAssoc','User',
       relations=3D['user','typed_assocs'],
       delete=3D['nullify','cascade'],
       keys=3D['FK_User_id','id']
     ),
     Association('TypedAssoc','Address',
       relations=3D['address','typed_assocs'],
       delete=3D['nullify','cascade'],
       keys=3D['FK_Address_id','id']

   i.e.  User <----->> TypedAssoc <<-----> Address

> However, I am surprised that in the schema dump for the
> created sqlite database, none of these relation names
> (user_address, etc) show up! How does he know about
> them when re-creating the db from the schema dump
> (which he seems to do just fine) ?

The relations do not appear in the sql dump of tables --they do not
exist, all the informations about the relationships is stored within
foreign keys. However, when the databases support it, the framework adds
integrity constraints to the db schema, whose names are the relations's
name: (from model StoreEmployees)

> mdl_generate_DB_schema.py -A -c StoreEmployees/pymodel_StoreEmployees.py
[...]
ALTER TABLE ADDRESS ADD CONSTRAINT toEmployee=20
  FOREIGN KEY (FK_EMPLOYEE_ID)     ^^^^^^^^^^
  REFERENCES EMPLOYEE(ID)
  INITIALLY DEFERRED
[...]

However the framework does not make any use of these constraints --since
it already respects them at the object level. They are just put in the
db by mdl_generated_DB_schema's '-F' option: "create foreign key
constraints", this can be useful e.g. if you want to interact w/ the db
with a raw sql adaptor without worrying about the integrity of your data
since these constraints are also declared and enforced by the db-server.

        Cheers,

-- S=E9bastien.

[Modeling-users] test_generate_python_code.sh

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

Hi, i notice that 0.9pre12 has a new test. When I run it (after running 
the
others), I get the terminal output below. What does "OK: Failed" mean 
;-?
Oh, and this one really takes a long time (minutes) to execute...

mario

% sh ./test_generate_python_code.sh
OK:    Success: AuthorBooks / -B w/ 
testPackages/AuthorBooks.ori/model_AuthorBooks.xml
OK:    Success: AuthorBooks / -C w/ 
testPackages/AuthorBooks.ori/model_AuthorBooks.xml
OK:    Success: AuthorBooks / -B w/ 
testPackages/AuthorBooks.ori/pymodel_AuthorBooks.py
OK:    Success: AuthorBooks / -C w/ 
testPackages/AuthorBooks.ori/pymodel_AuthorBooks.py
OK:    Success: StoreEmployees / -B w/ 
xmlmodels/model_StoreEmployees.xml
OK:    Success: StoreEmployees / -C w/ 
xmlmodels/model_StoreEmployees.xml
OK:    Success: StoreEmployees / -B w/ 
xmlmodels/model_StoreEmployees2.xml
OK:    Success: StoreEmployees / -C w/ 
xmlmodels/model_StoreEmployees2.xml
OK:    Success: StoreEmployees / -B w/ 
testPackages/StoreEmployees.ori/pymodel_StoreEmployees.py
OK:    Success: StoreEmployees / -C w/ 
testPackages/StoreEmployees.ori/pymodel_StoreEmployees.py
OK:    Success: StoreEmployees / -B w/ 
xmlmodels/pymodel_StoreEmployees2.py
OK:    Success: StoreEmployees / -C w/ 
xmlmodels/pymodel_StoreEmployees2.py
OK:    Success: StoreEmployees / -C w/ 
xmlmodels/model_StoreEmployees3.xml
./test_generate_python_code.sh: 
testPackages/StoreEmployees/Executive.py: No such file or directory
./test_generate_python_code.sh: 
testPackages/StoreEmployees/SalesClerk.py: No such file or directory
./test_generate_python_code.sh: 
testPackages/StoreEmployees/Employee.py: No such file or directory
OK:    Failed:  StoreEmployees / -B w/ 
xmlmodels/model_StoreEmployees3.xml
OK:    Success: StoreEmployees / -C w/ 
xmlmodels/pymodel_StoreEmployees3.py
./test_generate_python_code.sh: 
testPackages/StoreEmployees/Executive.py: No such file or directory
./test_generate_python_code.sh: 
testPackages/StoreEmployees/SalesClerk.py: No such file or directory
./test_generate_python_code.sh: 
testPackages/StoreEmployees/Employee.py: No such file or directory
OK:    Failed:  StoreEmployees / -B w/ 
xmlmodels/pymodel_StoreEmployees3.py
%

Re: [Modeling-users] Re: attaching information to a relation

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

On Jeudi, ao=FB 7, 2003, at 01:38, Mario Ruggier wrote:
> On Mardi, ao=FB 5, 2003, at 00:01, Sebastien Bigaret wrote:
>>
>>         Hi Mario,
>>
>> Mario Ruggier <ma...@ru...> wrote:
>>> On Lundi, ao=FB 4, 2003, at 20:49, Sebastien Bigaret wrote:
>>>> Mario wrote:
>>>>> just wondering how this can be best done... as a simple example,
>>>>> assume a Person and an Address tables. A Person may have
>>>>> more than one address, but each address may be categorized
>>>>> as being "primary", "secondary", "private", "work", or anything
>>>>> a priori unknown, Where does one best stick this information?
>>>>
>>>> I think this is what uml calls a "qualified association".
>>>
>>> Thanks for the explanation(s) below...
>>> This would work just fine, if an Address belongs (exclusively)
>>> to any one Person. What I am looking for is a way to reuse
>>> the same Address for different people, but the type of
>>> relation may be different each time. E.g.
>>>
>>> Mr. Dough's lives in a Villa, across from the beach (private =
Address)
>>> Ladi Lean is the housemaid for Mr. Dough (work Address)
>>> Mr. Dough's little sister spends summers at his villa (secondary=20
>>> Address)
>>> ...
>>>
>>> The most natural thing to me would be to add a "property"
>>> to the association, if that'd be allowed. I guess one would have
>>> to make an addditional association table for this?
>>
>> Okay, I didn't understand you properly. Now it's clear, you need
>> qualified many-to-many associations. Here is a draft guideline for
>> modeling a many-to-many relationship:
>
> Very nice, thanks a lot. The association table is easy enough to
> create (especially with the wonderfully expressive PyModel
> Association statement). Thanks also for the sample code
> to do the important manipulations. I will let you know what i
> discover when doing such things... (have not played
> with this part yet...). It would also certainly be great
> to have a test/howto for this.
>
> I have a question here: is it a good idea to re-use such
> assoc tables to relate in a many-2-many way any arbitrary
> pair of tables? An m2m relationship with a type seems to
> me a frequently occurring situation, and it seems like a lot
> of overhead to declare a dedicated assoc table per relation.
> As an example, consider:
>
>   Entity('User',
>     properties=3D[
>       AString('firstname',isRequired=3D1),
>       AString('lastname',isRequired=3D1),
>       ...
>     ]
>   ),
>
>   Entity('Address',
>     properties=3D[
>       AString('street'),
>       ...
>     ]
>   ),
>
>   Entity('Organization',
>     properties=3D[
>       AString('name',isRequired=3D1),
>       AString('type',isRequired=3D1),
>     ],
>   ),
>
>   Entity('ManyToMany_Type',
>     properties=3D[
>       AString('type'),
>     ]
>   ),
>
>
>  Association('User','ManyToMany_Type',
>     relations=3D['addresses','user'],
>     delete=3D['cascade','nullify'],
>     keys=3D['FK_Address_id','id'] # what should this fk be named?
>   ),
>
>   Association('Address','ManyToMany_Type',
>     relations=3D['users','address'],
>     delete=3D['cascade','nullify'],
>     keys=3D['FK_User_id','id'] # what should this fk be named?
>   ),
>
>  Association('User','ManyToMany_Type',
>     relations=3D['organizations','user'],
>     delete=3D['cascade','nullify'],
>     keys=3D['FK_Organization_id','id'] # what should this fk be named?
>   ),
>
>   Association('Organization','ManyToMany_Type',
>     relations=3D['users','organization'],
>     delete=3D['cascade','nullify'],
>     keys=3D['FK_User_id','id'] # what should this fk be named?
>   ),
>
> This, the same assoc table is used for the m2m relations
> between User<>Address and User<>Organization.
> Is this a good way?

I should have played with the above case a little more, as
it will not work like this -- because this will attempt to create
two relations on the ManyToMany_Type (now TypedAssoc) table,
that are both named 'user'. The mdl_validate error given is:

ValueError: Attempt to insert a relationship in entity TypedAssoc but a=20=

key named 'user' is already registered.

However, if i change the name of the relation on the Assoc table
(e.g. following a convention such as source_target), then the
db is created ok. Thus the assocs will change to:

   Association('User','TypedAssoc',
     relations=3D['organizations','user_organization'],
     delete=3D['cascade','nullify'],
     keys=3D['FK_Organization_id','id'],
   ),
   Association('Organization','TypedAssoc',
     relations=3D['users','organization_user'],
     delete=3D['deny','nullify'],
     keys=3D['FK_User_id','id'],
   ),
   Association('User','TypedAssoc',
     relations=3D['addresses','user_address'],
     delete=3D['cascade','nullify'],
     keys=3D['FK_Address_id','id']
   ),
   Association('Address','TypedAssoc',
     relations=3D['users','address_user'],
     delete=3D['deny','nullify'],
     keys=3D['FK_User_id','id']
   ),

However, I am surprised that in the schema dump for the
created sqlite database, none of these relation names
(user_address, etc) show up! How does he know about
them when re-creating the db from the schema dump
(which he seems to do just fine) ?

> Cheers, mario

[Modeling-users] few misc issues with sqlite adaptor

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

Hi,

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


2. when running mdl_validate_model on a model that
uses "text" as externalType (using SQLite adaptor):

  * Error(s):
    - Invalid SQL type: 'text' (valid for this adaptor: ['char', 'date', 
'varchar', 'timestamp', 'time', 'int', 'integer', 'float', 'numeric'])


3. When running mdl_* utility scripts, the main cfg (pointed to by 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.


4. When running mdl_generate_DB utility script, and specifying a
--admin-dsn on the command line, and the db name in this dsn is
different than the db name specified in the pymodel, then an empty
file with the dsn_db name is created, and a proper sqlite db fis
created in a file with the pymodel_db name.


Cheers, mario

Re: [Modeling-users] Re: attaching information to a relation

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

On Mardi, ao=FB 5, 2003, at 00:01, Sebastien Bigaret wrote:
>
>         Hi Mario,
>
> Mario Ruggier <ma...@ru...> wrote:
>> On Lundi, ao=FB 4, 2003, at 20:49, Sebastien Bigaret wrote:
>>> Mario wrote:
>>>> just wondering how this can be best done... as a simple example,
>>>> assume a Person and an Address tables. A Person may have
>>>> more than one address, but each address may be categorized
>>>> as being "primary", "secondary", "private", "work", or anything
>>>> a priori unknown, Where does one best stick this information?
>>>
>>> I think this is what uml calls a "qualified association".
>>
>> Thanks for the explanation(s) below...
>> This would work just fine, if an Address belongs (exclusively)
>> to any one Person. What I am looking for is a way to reuse
>> the same Address for different people, but the type of
>> relation may be different each time. E.g.
>>
>> Mr. Dough's lives in a Villa, across from the beach (private Address)
>> Ladi Lean is the housemaid for Mr. Dough (work Address)
>> Mr. Dough's little sister spends summers at his villa (secondary=20
>> Address)
>> ...
>>
>> The most natural thing to me would be to add a "property"
>> to the association, if that'd be allowed. I guess one would have
>> to make an addditional association table for this?
>
> Okay, I didn't understand you properly. Now it's clear, you need
> qualified many-to-many associations. Here is a draft guideline for
> modeling a many-to-many relationship:

Very nice, thanks a lot. The association table is easy enough to
create (especially with the wonderfully expressive PyModel
Association statement). Thanks also for the sample code
to do the important manipulations. I will let you know what i
discover when doing such things... (have not played
with this part yet...). It would also certainly be great
to have a test/howto for this.

I have a question here: is it a good idea to re-use such
assoc tables to relate in a many-2-many way any arbitrary
pair of tables? An m2m relationship with a type seems to
me a frequently occurring situation, and it seems like a lot
of overhead to declare a dedicated assoc table per relation.
As an example, consider:

   Entity('User',
     properties=3D[
       AString('firstname',isRequired=3D1),
       AString('lastname',isRequired=3D1),
       ...
     ]
   ),

   Entity('Address',
     properties=3D[
       AString('street'),
       ...
     ]
   ),

   Entity('Organization',
     properties=3D[
       AString('name',isRequired=3D1),
       AString('type',isRequired=3D1),
     ],
   ),

   Entity('ManyToMany_Type',
     properties=3D[
       AString('type'),
     ]
   ),


  Association('User','ManyToMany_Type',
     relations=3D['addresses','user'],
     delete=3D['cascade','nullify'],
     keys=3D['FK_Address_id','id'] # what should this fk be named?
   ),

   Association('Address','ManyToMany_Type',
     relations=3D['users','address'],
     delete=3D['cascade','nullify'],
     keys=3D['FK_User_id','id'] # what should this fk be named?
   ),

  Association('User','ManyToMany_Type',
     relations=3D['organizations','user'],
     delete=3D['cascade','nullify'],
     keys=3D['FK_Organization_id','id'] # what should this fk be named?
   ),

   Association('Organization','ManyToMany_Type',
     relations=3D['users','organization'],
     delete=3D['cascade','nullify'],
     keys=3D['FK_User_id','id'] # what should this fk be named?
   ),

This, the same assoc table is used for the m2m relations
between User<>Address and User<>Organization.
Is this a good way?


Cheers, mario

Re: [Modeling-users] Re: Installation Guide

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

        Hi SoaF,

SoaF-BSD <so...@la...> wrote:
> On Monday 04 August 2003 20:34, Sebastien Bigaret wrote:
> > Could you be more explicit please? I'm running all the tests for py2.1
> > and py2.2 systematically, I'm also using the ZModeler w/ zope 2.6.1 and
> > its py2.1, and never encountered any problem regarding
> > finalize_docString().
> >
>=20
> I'm too busy to fix that right now ..=20
> the problem occur in ZModeling w/ Zope 2.6.1 running on=20
> python 2.2 ( i know i shouldn't do this but as the only trouble
> i get is in finalize_docString() this isn't a big deal . I just comment
> out this and work's fine for me.=20

That's ok. I thought you had problems w/ zope 2.6.1 and its py2.1 and
that you switched to zope 2.6.2 w/ py2.2 because of these problems.

  I must admit I didn't try that. If you have something like a
  traceback, feel free to send it to me. In the meantime, disabling
  finalize_docString() is okay and has no consequences except that some
  docstrings for Entity won't be what they should be.

...But you do not care about docstrings these at runtime, do you?! :)

-- S=E9bastien.

Re: [Modeling-users] Re: attaching information to a relation

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

        Hi Mario,

Mario Ruggier <ma...@ru...> wrote:
> On Lundi, ao=FB 4, 2003, at 20:49, Sebastien Bigaret wrote:
> > Mario wrote:
> >> just wondering how this can be best done... as a simple example,
> >> assume a Person and an Address tables. A Person may have
> >> more than one address, but each address may be categorized
> >> as being "primary", "secondary", "private", "work", or anything
> >> a priori unknown, Where does one best stick this information?
> >
> > I think this is what uml calls a "qualified association".
>=20
> Thanks for the explanation(s) below...
> This would work just fine, if an Address belongs (exclusively)
> to any one Person. What I am looking for is a way to reuse
> the same Address for different people, but the type of
> relation may be different each time. E.g.
>=20
> Mr. Dough's lives in a Villa, across from the beach (private Address)
> Ladi Lean is the housemaid for Mr. Dough (work Address)
> Mr. Dough's little sister spends summers at his villa (secondary Address)
> ...
>=20
> The most natural thing to me would be to add a "property"
> to the association, if that'd be allowed. I guess one would have
> to make an addditional association table for this?

Okay, I didn't understand you properly. Now it's clear, you need
qualified many-to-many associations. Here is a draft guideline for
modeling a many-to-many relationship:

  - create entity PersonAdress --yes, this is the correlation table,

  - add attribute 'category' to it

  - add a to-many relationship from Person to PersonAdress, and its
    inverse (to-one): Person <---->> PersonAdress

  - add the two relationships: PersonAdress <<-------> Address

  - in Person, then add a method for getting addresses:

      def getAddresses(self, type=3DNone):
        if type is None:
          return self.valueForKeyPath('toPersonAddresses.toAddress')
        else:
          PAs=3D[pa for pa in self.getPersonAddresses() if pa.getType()=3D=
=3Dtype]
          addrs=3D[]
          [addrs.extend(pa.getPerson()) for pa in PAs]
          return addrs

   - add a similar one in Address if you need the inverse (from Address
     to Person),

   - be careful about setters, you need to manipulate the intermediate
     object, something like this:

       def addToAddresses(self, address, type):
         # you may also want to check that it's not already added
         # under an other category, or under the same category
         _pa=3DPersonAddress(type=3Dtype)
         self.editingContext().insert(_pa)
         self.addToPersonAddresses(_pa)
         _pa.setPerson(self)
         _pa.setAddress(address)
         address.addToPersonAddresses(_pa)

       def removeFromAddresses(self, address, type=3DNone):
         _pa=3D[pa in self.getPersonAddresses() if address =3D=3D pa.getAdd=
ress()]
         if type:
           _pa=3D[pa in _pa if pa.getType() =3D=3D type]
         if not _pa:
           raise ValueError, 'Cannot find address'
         # here you can get one or more PersonAddress, depending on
         # whether you allow the same Address to be registered under a
         # single category or not

         _pa=3D_pa[0] #or iterate on all, which could be handy if you want
                    #to remove all relations to 'address' when type=3D=3DNo=
ne
         self.removeFromPersonAddresses(_pa)
         _pa.getAddress().removeFromPersonAddresses(_pa)
         _pa.setAddress(None)
         _pa.setPerson(None)
         self.editingContext().remove(_pa)


  I didn't try it, though ;) I may create a special unittest suite for
  this, and use it to document many-to-many... If you try this, I'd like
  to hear from you, and I'll try to help to my best if have any problem.


        Cheers,

-- S=E9bastien.

Re: [Modeling-users] Re: attaching information to a relation

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

On Lundi, ao=FB 4, 2003, at 20:49, Sebastien Bigaret wrote:
> Mario wrote:
>> just wondering how this can be best done... as a simple example,
>> assume a Person and an Address tables. A Person may have
>> more than one address, but each address may be categorized
>> as being "primary", "secondary", "private", "work", or anything
>> a priori unknown, Where does one best stick this information?
>
> I think this is what uml calls a "qualified association".

Thanks for the explanation(s) below...
This would work just fine, if an Address belongs (exclusively)
to any one Person. What I am looking for is a way to reuse
the same Address for different people, but the type of
relation may be different each time. E.g.

Mr. Dough's lives in a Villa, across from the beach (private Address)
Ladi Lean is the housemaid for Mr. Dough (work Address)
Mr. Dough's little sister spends summers at his villa (secondary=20
Address)
...

The most natural thing to me would be to add a "property"
to the association, if that'd be allowed. I guess one would have
to make an addditional association table for this?

mario



> This is how I
> would model this:
>
>   - add a 'category' attribute to entity Address,
>
>   - add to the Person class methods such as:
>
>       ----------------------------------------
>       def getAddresses(self, type=3DNone):
>         """
>         Returns addresses of a given type, or all addresses if type
>         is None or omitted
>         """
>         self.willRead()
>         if type is None:
>           return self._addresses
>         else:
>           return self.editingContext().fetch('Address',
>                                              'type =3D=3D '%s'"%type)
>       ----------------------------------------
>
>   You can also do in-memory filtering w/ a qualifier, after the
>
>       ----------------------------------------
>       from Modeling.Qualifier import KeyValueQualifier
>       from Modeling.Qualifier import QualifierOperatorEqual
>       from Modeling.Qualifier import filteredArrayWithQualifier
>
>       def getAddresses(self, type=3DNone):
>         """
>         Returns addresses of a given type, or all addresses if type
>         is None or omitted
>         """
>         self.willRead()
>         if type is None:
>           return self._addresses
>         else:
>           q=3DKeyValueQualifier('category', QualifierOperatorEqual, =
type)
>           return filteredArrayWithQualifier(self.getAddresses(), q)
>       ----------------------------------------
>
>   (of course, when all the types are known, you can also use
>   inheritance)
>
>         Cheers,
>
> -- S=E9bastien.

Re: [Modeling-users] Re: Installation Guide

[SoaF-BSD <so...@la...>]

On Monday 04 August 2003 20:34, Sebastien Bigaret wrote:
>         Hi,

>
> Could you be more explicit please? I'm running all the tests for py2.1
> and py2.2 systematically, I'm also using the ZModeler w/ zope 2.6.1 and
> its py2.1, and never encountered any problem regarding
> finalize_docString().
>

I'm too busy to fix that right now .. 
the problem occur in ZModeling w/ Zope 2.6.1 running on 
python 2.2 ( i know i shouldn't do this but as the only trouble
i get is in finalize_docString() this isn't a big deal . I just comment
out this and work's fine for me. 


Bye Bye .. 

[Modeling-users] Re: attaching information to a relation

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

Mario wrote:
> just wondering how this can be best done... as a simple example,
> assume a Person and an Address tables. A Person may have
> more than one address, but each address may be categorized
> as being "primary", "secondary", "private", "work", or anything
> a priori unknown, Where does one best stick this information?

I think this is what uml calls a "qualified association". This is how I
would model this:

  - add a 'category' attribute to entity Address,

  - add to the Person class methods such as:

      ----------------------------------------
      def getAddresses(self, type=3DNone):
        """
        Returns addresses of a given type, or all addresses if type
        is None or omitted
        """
        self.willRead()
        if type is None:
          return self._addresses
        else:
          return self.editingContext().fetch('Address',=20
                                             'type =3D=3D '%s'"%type)
      ----------------------------------------

  You can also do in-memory filtering w/ a qualifier, after the

      ----------------------------------------
      from Modeling.Qualifier import KeyValueQualifier
      from Modeling.Qualifier import QualifierOperatorEqual
      from Modeling.Qualifier import filteredArrayWithQualifier

      def getAddresses(self, type=3DNone):
        """
        Returns addresses of a given type, or all addresses if type
        is None or omitted
        """
        self.willRead()
        if type is None:
          return self._addresses
        else:
          q=3DKeyValueQualifier('category', QualifierOperatorEqual, type)
          return filteredArrayWithQualifier(self.getAddresses(), q)
      ----------------------------------------

  (of course, when all the types are known, you can also use
  inheritance)

        Cheers,

-- S=E9bastien.

[Modeling-users] Re: Installation Guide

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

        Hi,

  Sorry for replying so lately, but for some reasons I did not get you
  emails, I've just discover them now when checking the mailing list archiv=
es
  for another reason. Strange.

Back on the subject:

Mario wrote:
> On Samedi, ao=FBt 2, 2003, at 02:14, SoaF-BSD wrote:
>=20
> > Something come to my mind since i need to install the modeling
> > quickly by night .. and i don't use it since a while . There is no
> > Installation Guide on the Website ? Beside I think i gonna find
> > a INSTALL.txt somewhere.
>=20
> Good point! There is an INSTALL at top level, and it is old
> (still mentions PyXML, and does not mention how to run the tests).
> I guess Dependencies (also old) and Install should be combined
> into one file, and possibility also exposed as a single web page,
> separate from the manual.

I say << Good point! >> as well ;) This is probably how it should be.

> Plus, I find annoying that there is the multitude of files called
> README, TODO, INSTALL, CHANGES, ... in the distribution tree.
> This is tricky to keep updated, and rather confusing. Plus, a global
> HISTORY file, to be able to quickly check back for what
> change was introduced in which version, is never where I
> expect to find it (it is CHANGES one level down from top
> dir in distribution). I think any one of these files should
> appear in the dist tree strictly only once.

Okay, they need to be gathered in a single place, in the root
directory. I'll check that and make the changes. And CHANGES will be put
one directory up.

SoaF-BSD wrote:
> And another thing we should add is a FAQ. Since I=20
> encounter small troube last night when i try to=20
> use the ZModelisation Tool.=20
>=20
> I managed to use ptyhon 2.2 and Zope 2.6.1=20
> to run the modeling but I need to patch one=20
> thing. In fact there is a bug in finalize_docString().
> This use inspect and the inspect from 2.1=20
> doesn't seems to have the same behaviour=20
> as in 2.2.=20

Could you be more explicit please? I'm running all the tests for py2.1
and py2.2 systematically, I'm also using the ZModeler w/ zope 2.6.1 and
its py2.1, and never encountered any problem regarding
finalize_docString().

        Cheers,

-- S=E9bastien.

Re: [Modeling-users] SQLite adaptor (more buglets)

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

Hi,

thanks for all the super-quick corrections, and a new release!
I believe you have actually fixed everything reported in all the mails
(and that needed fixing). Only two unclosed questions, answered below.


>> 1. Setting a .cfg, (that sets default adapter to SQLite, and uses the
>> interpolation feature of ConfigParser to set the data dir), pointing 
>> to
>> it via MDL_DB_CONNECTIONS_CFG, and running a number of
>> things gives an error, e.g:
> [...]
>>    File "/usr/lib/python2.2/ConfigParser.py", line 293, in get
>>      raise InterpolationError(key, option, section, rawval)
>> ConfigParser.InterpolationError: Bad value substitution:
>>          section: [AuthorBooks]
>>          option : database
>>          key    : db_data_dir
>>          rawval : %(db_data_dir)s/db_AuthorBooks.db
>
>   I do not know this interpolation feature, but it seems that you cfg 
> file is
>   not syntacticly correct.

Ah, yes, sorry about that.
What was wrong was that I had the "db_data_dir=..." variable
under one of the database names, and not under DEFAULT
(in fact was working for one but not the other db).
I guess cfg manages namespace scopes (quite nice).

[...]

>> However, it should be noted that running the test scripts, e.g.:
>> % python ./test_EditingContext_Global.py -r -d SQLite
>> does create the SQLite db, except that it uses the SQLite.cfg in the  
>> tests
>> dir.
>
> Yes, that's intended: tests uses their own settings (the .cfg file in
> tests/).
>
>> But, looking at the test scripts, the code used to create the db is  
>> very
>> different
>> than the code in the utility script.
>
> Could you be more specific? On my side, both test_EC_Global*.py 's
> reinitDB() and mdl_generate_DB_schema's databaseSchemaWithOptions()
> iterate on sql expressions returned by the adaptor's
> SchemaGeneration.schemaCreationStatementsForEntities().

Sorry, had looked at the two much too quickly... yes the two are
logically equivalent.

Thanks, mario

[Modeling-users] Modeling/Core v0.9pre12 released

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

        Hi all,

Release v0.9pre12 is out, and consists in bug-fixes mainly:

  - EditingContext.fetch() cannot return duplicates in the result set
    anymore; this happened when the fetch specification implied two
    tables or more are joined. EditingContext.fetchCount() has been
    fixed accordingly.
=20=20
  - The adaptor layer for SQLite is now included in the distribution.
    (it is officially supported since 0.9pre9 but was omitted from the
    source distribution).
=20=20
  - Qualifier operator IN accepts long ints.
=20=20
  - CustomObject.snapshot() does not return an improper result for
    to-many relationships anymore.

    This has been already discussed on the mailing-list. However, the
    fix included here is different from what I announced: when a to-many
    relationship is still faulted, snapshot() now returns an instance of
    CustomObject.Snapshot_ToManyFault.

    See the documentation for this class and for snapshot() for details.
    http://modeling.sourceforge.net/API/Modeling-API/public/Modeling.Custom=
Object.Snapshot_ToManyFault-class.html
    http://modeling.sourceforge.net/API/Modeling-API/public/Modeling.Custom=
Object.CustomObject-class.html#snapshot

  I'll now try to focus on documentation, esp. for PyModels. FYI, the
next release will probably also include the Oracle Adaptor Layer
(already available in patch #774894, if you want to give it a try:
https://sf.net/tracker/index.php?func=3Ddetail&aid=3D774894&group_id=3D5893=
5&atid=3D489337)

-- S=E9bastien.



------------------------------------------------------------------------
0.9-pre-12 (2003/08/03)
-----------------------

  * Fixed bug #780495: when ec.fetch() is joining two tables or more, the
    returned set of objects could have duplicates.

  * Fixed bug #774989: improper result returned by CustomObject.snapshot()
    wrt tomany relationships --see CustomObject.snapshot() documentation for
    details.

  * Fixed bug #779775, on behalf of Yannick Gingras who reported the bug and
    gave the patch fixing it.

  * Fixed bug #781884: SQLiteAdaptorLayer: dropping and creating a database
    was not possible (and was failing w/ an ugly traceback)

  * Fixed MANIFEST.in and setup.py: the SQLite adaptor layer was omitted in
    the source distribution! Thanks Mario for reporting.

  * Model.loadModel() now automatically build() a pymodel, as suggested by
    Mario <ma...@ru...>

------------------------------------------------------------------------

Re: [Modeling-users] Double Result

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

        Hi,

  A complete fix for bug #780495 (when ec.fetch() is joining two tables
  or more, the returned set of objects could have duplicates) has been
  submitted onto the main trunk. Corrected files are:

SQLExpression.py v1.21
DatabaseAdaptors/MySQLAdaptorLayer/MySQLSQLExpression.py v1.6
DatabaseAdaptors/PostgresqlAdaptorLayer/PostgresqlSQLExpression.py v1.6
test_SQLExpression.py v1.7

  Details: the 'DISTINCT' keywork is only added when needed, ie when two
           tables or more are joined. The corresponding SQL statement
           for counting rows / ec.fetchCount() is generated following
           the general rules exposed in the previous post (incl. below).

-- S=E9bastien.


Sebastien Bigaret <sbi...@us...> wrote:
> Jer...@fi... wrote:
> [About SELECT DISTINCT]
> > I'm thinking that you really need to check this carefully since sometim=
es
> > we don't want to use disctinct, no ? hum deleting or count may have the
> > same trouble no ?=20
> >=20
> > I haven't work w/ modeling since 5 months right now so I may say wrong=
=20
> > things .. pay caution
>=20
> No, you're right as far as ec.fetchCount() is concerned: it is also
> affected by this bug. Alas, I've no patch to propose for fetchCount()
> yet: I can't find a portable way of making this (see below).
>=20
>   Deletes, inserts or updates are not affected by this bug, because the
>   framework never joins tables for these operations.
>=20
> About fetch(): I can't think of any situations where you would not want
> the DISTINCT stuff. If you can think of such situations, I think it's
> time to speak ;)   However, I'm still not sure that the DISTINCT keyword
> will always be added to any select statements, it can be better to add
> it only when tables are joined.
>=20
>=20
> Now back on fetchCount(): I've found these two forms:
>=20
> Form #1
> -------
> SELECT  count(DISTINCT(t0.id)) [as count]
> FROM WRITER t0
> INNER JOIN BOOK t1 ON t0.ID=3Dt1.FK_WRITER_ID
> WHERE ((t0.AGE < 100 OR t0.AGE > 200) AND t1.title LIKE '%');
>=20
> Form #2
> -------
> SELECT  count(*) from (
> SELECT DISTINCT t0.ID,t0.FIRST_NAME,t0.LAST_NAME,t0.AGE,t0.BIRTHDAY,t0.FK=
_WRITER_ID
> FROM WRITER t0
> INNER JOIN BOOK t1 ON t0.ID=3Dt1.FK_WRITER_ID
> WHERE ((t0.AGE < 100 OR t0.AGE > 200) AND t1.title LIKE '%'))
>=20
> And here is how db-server accepts them:
>=20
>    |Postgres| MySQL | SQLite | O9i | O8i |
> ---+--------+-------+--------+-----+-----|
> #1 |   Y    |   Y   |   N    |  Y  |  Y  |
> ---+--------+-------+--------+-----+-----|
> #2 |   Y[1] |   N   |   Y    |  Y  |  Y  |
> ---+--------+-------+--------+-----+-----+
>=20
> [1] for postgresql, 'as foo' should be appended at the end of the SQL
>     statement
>=20
> Form #1 is clearly an extension of ANSI SQL-92, but I can't find whether
> form #2 is SQL-92 or not; I suspect it is, and that a from statement can
> be a sub-query (the so-called table subqueries), but I'd like to hear
> from you if you're sure about it.
>=20
>   I think I'll probably make #2 the default in SQLExpression, and use #1
>   for MySQL.

[Modeling-users] attaching information to a relation

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

Hi,

just wondering how this can be best done... as a simple example,
assume a Person and an Address tables. A Person may have
more than one address, but each address may be categorized
as being "primary", "secondary", "private", "work", or anything
a priori unknown, Where does one best stick this information?

Thanks, mario

Re: [Modeling-users] Installation Guide

[SoaF-BSD <so...@la...>]

On Saturday 02 August 2003 09:24, Mario Ruggier wrote:

And another thing we should add is a FAQ. Since I 
encounter small troube last night when i try to 
use the ZModelisation Tool. 

I managed to use ptyhon 2.2 and Zope 2.6.1 
to run the modeling but I need to patch one 
thing. In fact there is a bug in finalize_docString().
This use inspect and the inspect from 2.1 
doesn't seems to have the same behaviour 
as in 2.2. 

This is a good news i think since having both
modeling w/ 2.1 python (XML / mxDate.. ) and
2.2, is awfull. So I will try to patch this bug 
nicely (I just comment the finalize_docString)
and next I will write a short faq entry on 
how to install _smothely_ ZModeling.. 

Re: [Modeling-users] SQLite adaptor (buglets)

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

>> 2. When running with SQLite, an admin-connection-dict should not be 
>> required?
>
> Even if sqlite has no notion of administrators, I'll keep it here: , 
> for
> consistency, and because one of reason why the long option (with no
> short equivalent) is required is that it makes it quite harder to drop
> by mistake a db possibly w/ valuable data.

Sounds like a good choice. And now that creation of sqlite db's
actually works, it is much less annoying than before ;)

mario

Re: [Modeling-users] SQLite adaptor (buglets)

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

Mario Ruggier <ma...@ru...> wrote:
> 2. When running with SQLite, an admin-connection-dict should not be requi=
red?

Even if sqlite has no notion of administrators, I'll keep it here: , for
consistency, and because one of reason why the long option (with no
short equivalent) is required is that it makes it quite harder to drop
by mistake a db possibly w/ valuable data.

-- S=E9bastien.

Re: [Modeling-users] SQLite adaptor (buglets)

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

I wrote:
[About: failure/traceback when re-creating a sqlite db]
> Okay, the error is horrible, this should not happen, I'll check
> this. However, true, I'm not sure the adaptor for SQLite can be able to
> create a database, I'm not sure this can be easily done w/ pure python
> (I mean, no os.system()) --but it should raise accordingly, and this
> should be documented.

  I must have been quite tired yesterday when writing this: simply
  opening a connection to a non-existent sqlite db is sufficient to
  create the database. That's how it's done now (and 'drop database' is
  implemented with os.unlink()).

-- S=E9bastien.