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

Re: [Modeling-users] tests failing

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

        Hi John and all,

John Lenton <jl...@gm...> wrote:
> I'm getting ready to create test cases for several of the patches that
> are emerging from the work I've been doing in the last months; to
> avoid regressions, I'm trying to make sure I have everything set up to
> run the tests correctly, but several of the tests are failing, both in
> 0.9-pre-17.1 and current cvs, with the following message:
>=20
> ValidationException: Validation for key books failed:
> - Key is required but value is void
> Validation for key OBJECT_WIDE_VALIDATION failed:
> - Validation of object <test_EditingContext_Global.Writer_test07
> object at 0x40ad3c6c> as a whole failed
>=20
> the tests are from test_EditingContext_Global.py:
>   test_07_savechanges_01
>   test_09_savechanges_03
>   test_10_saveChanges_04
>   test_12_fetchingDoesNotUpdateSnapshot
>   test_17b_insertedObject_and_FK_as_classProperty
>   test_20_snapshot
>   test_22_cancel_delete
>=20
> apart from these seven errors I get three failures, in
>=20
>   test_CooperatingObjectStoreNeededNotification.py:
>     test_01_initialState
>   test_EditingContext_Global.py:
>     test_00_insertObject_loads_databaseContexts
>     test_08_savechanges_02
>=20
> and two extra failures in cvs head that seem to be harmless (different
> ordering of attributes in a sql statement).

  I confirm your observations and the errors you see w/ the ./run.py -g
stuff also appear here.  The fact is, I completely forgot about that
option, and I do not use it at all. Sorry about that.

  Before this is fixed, you can have all the tests run w/ the procedure
  described in the README: ./run.py (NO -g), plus the three
  ./test_EditingContext_XXX.py scripts.

--> The four test script should give zero error & zero warning w/
    0.9pre17.1 (this is part of the procedure rnu before every release)

> am I doing something wrong? I'm guessing the README is outdated,
> because I tried that and it was even worse; I ran
> 'test_EditingContext_Global.py -r' and
> 'test_EditingContext_Global_Inheritance.py -r', and then 'run.py -g'.
> These two give errors every time, complaining that
>=20
> DROP INDEX WRITER_pkey
> error: Couldn't evaluate expression DROP INDEX WRITER_pkey. Reason:
> psycopg.ProgrammingError:ERROR:  cannot drop index writer_pkey because
> constraint writer_pkey on table writer requires it
> HINT:  You may drop constraint writer_pkey on table writer instead.

Another bug here. Workaround: to regenerate the test databases, connect
to the admin. db template1, then

    DROP DATABASE "AUTHOR_BOOKS";
    CREATE DATABASE "AUTHOR_BOOKS";
    DROP DATABASE "STORE_EMPLOYEES";
    CREATE DATABASE "STORE_EMPLOYEES"

and finally run the scripts:
    ./test_EditingContext_Global.py -r
    ./test_EditingContext_Global_Inheritance.py -r

Your test-dbs should then be okay.

> Also, one thing that isn't mentioned in the README is that the
> database must be created with -E LATIN1, or it will produce an(other)
> error.

Third bug --could you be more explicit about the error? What is the
default encoding you use, and how can I reproduce it here (an other -E
option?) ?

If I may ask and I you have some time, could you submit bug reports
@sf.net please?

    Anyway thanks a lot for the reports!

-- S=E9bastien.

Re: [Modeling-users] CustomObject.globalID() problem

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

no...@ti... wrote:
> On 04 Oct 2004 17:53:04 +0200
> Sebastien Bigaret <sbi...@us...> wrote:
>=20
> > You were probably too asleep ;)
>=20
> soooo true! just opened the src file and saw it... ^^;
> thanks, I got a problem here related to a 'just fetched'
> object that returns none as globalID, considered I couldn't read
> the code properly I highly doubt it's a bug in Modeling.
> I'll look into it better, and come up with a proper bug report
> if that's the case.

Okay; if you observe that a freshly fetched object has None as globalId(),
this is definitely a bug, so do not hesitate to report!

-- S=E9bastien.


> cheers
> --
> 'yours ZzZzleepy' Delio

[Modeling-users] tests failing

[John L. <jl...@gm...>]

I'm getting ready to create test cases for several of the patches that
are emerging from the work I've been doing in the last months; to
avoid regressions, I'm trying to make sure I have everything set up to
run the tests correctly, but several of the tests are failing, both in
0.9-pre-17.1 and current cvs, with the following message:

ValidationException: Validation for key books failed:
- Key is required but value is void
Validation for key OBJECT_WIDE_VALIDATION failed:
- Validation of object <test_EditingContext_Global.Writer_test07
object at 0x40ad3c6c> as a whole failed

the tests are from test_EditingContext_Global.py:
  test_07_savechanges_01
  test_09_savechanges_03
  test_10_saveChanges_04
  test_12_fetchingDoesNotUpdateSnapshot
  test_17b_insertedObject_and_FK_as_classProperty
  test_20_snapshot
  test_22_cancel_delete

apart from these seven errors I get three failures, in

  test_CooperatingObjectStoreNeededNotification.py:
    test_01_initialState
  test_EditingContext_Global.py:
    test_00_insertObject_loads_databaseContexts
    test_08_savechanges_02

and two extra failures in cvs head that seem to be harmless (different
ordering of attributes in a sql statement).

am I doing something wrong? I'm guessing the README is outdated,
because I tried that and it was even worse; I ran
'test_EditingContext_Global.py -r' and
'test_EditingContext_Global_Inheritance.py -r', and then 'run.py -g'.
These two give errors every time, complaining that

DROP INDEX WRITER_pkey
error: Couldn't evaluate expression DROP INDEX WRITER_pkey. Reason:
psycopg.ProgrammingError:ERROR:  cannot drop index writer_pkey because
constraint writer_pkey on table writer requires it
HINT:  You may drop constraint writer_pkey on table writer instead.

Also, one thing that isn't mentioned in the README is that the
database must be created with -E LATIN1, or it will produce an(other)
error.

-- 
John Lenton (jl...@gm...) -- Random fortune:
bash: fortune: command not found

Re: [Modeling-users] CustomObject.globalID() problem

[<no...@ti...>]

On 04 Oct 2004 17:53:04 +0200
Sebastien Bigaret <sbi...@us...> wrote:

> You were probably too asleep ;)

soooo true! just opened the src file and saw it... ^^;
thanks, I got a problem here related to a 'just fetched'
object that returns none as globalID, considered I couldn't read
the code properly I highly doubt it's a bug in Modeling.
I'll look into it better, and come up with a proper bug report
if that's the case.

cheers
--
'yours ZzZzleepy' Delio

Re: [Modeling-users] CustomObject.globalID() problem

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

        Hi Delio,

no...@ti... wrote:
> Hello all,
>=20
> looking at the code for globalID() in CustomObject I see that a new EC is=
 created on the fly and a globalID for self is looked up in it, question is=
 (and I'm probably too asleep) how does an newly created EC know about
> a globalID of an object fetched in another EC? I would have thought some =
sort of call back in the parentObjectStore but I can't see it in the code. =
Enlight me please :)
>=20
> ciao

You were probably too asleep ;)

CustomObject.globalID() does NOT create any EC, but
  1. asks self for its EC,
  2. asks that ec for the object's gid

  And since you're curious, here are some more: the EC stored in the
CustomObject is in fact a weakref to the real EC --that's why it is
initialized as a void lambda func BTW.  That weak reference is initialized =
by
the EC when the object is registered (either newly inserted or fetched from
the db), look at EC.recordObject() if you want to see the code!

-- S=E9bastien.



PS: oh, BTW, you'll probably also note the double underscore in
    'CustomObject.__editingContext'... and the ugly line:

        anObject._CustomObject__editingContext=3Dweakref.ref(self)
=20=20=20=20
    within EC.recordObject()
=20=20=20=20
    This comes from a time when I thought some fields should not be exposed
    (at least --since this is python:)-- not easily changed from the outsid=
e),
    so I choose to use the private name mangling for some variables.
    There are some examples of this in the framework alas, I think I'll cha=
nge
    them at some point: I now tend to think that this is not very pythonic,
    and that a single underscore and good documentation should be sufficient
    (or, at least, use a private method _setEC() instead of that explicit n=
ame
    mangling stuff in another class, isn't that supposed to be private after
    all ?-/).

[Modeling-users] CustomObject.globalID() problem

[<no...@ti...>]

Hello all,

looking at the code for globalID() in CustomObject I see that a new EC is created on the fly and a globalID for self is looked up in it, question is (and I'm probably too asleep) how does an newly created EC know about
a globalID of an object fetched in another EC? I would have thought some sort of call back in the parentObjectStore but I can't see it in the code. Enlight me please :)

ciao
--
Delio

Re: [Modeling-users] problem with the simplest of the model

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

        Hi Lorenzo,

  Sorry for the late answer, and thanks a lot for reporting and for the
patch.  It will be integrated as is into the main CVS trunk and in the
next release.  Thanks again!

-- S=E9bastien.


Lorenzo Gil Sanchez <lg...@si...> wrote:
> I wrote a patch yesterday to fix this problem so I'll attach it here for
> further review
>=20
> Lorenzo

Re: [Modeling-users] problem with the simplest of the model

[Lorenzo G. S. <lg...@si...>]

I wrote a patch yesterday to fix this problem so I'll attach it here for
further review

Lorenzo


El mar, 28-09-2004 a las 12:24 +0200, Lorenzo Gil Sanchez escribió:
> Hello,
> 
> I'm upgrade Modeling with the latest cvs and now, for a very simple
> model, the script mdl_generate_DB_schema.py gives me errors:
> 
> -----------------
> 
> mdl_generate_DB_schema.py -v -C --admin-dsn localhost:pets.sqlite:kk:zz
> model_pets2.py
> Loading the model...
> Error: model has errors:
> 
> Aborting
> 
> ------------------
> 
> As you can see I can't know what is wrong with my model, which I'll
> paste right here:
> 
> 
> from Modeling.PyModel import *
> 
> Entity.defaults['properties'] = [
>     APrimaryKey('id', isClassProperty=0, isRequired=1, doc='PK')
>     ]
> 
> model = Model('Pets', adaptorName='SQLite',
>               connDict={'database': 'pets.sqlite'}, version='0.1')
> 
> model.entities = [
>     Entity('Person',
>            properties = [AString('name', isRequired=1)]
>            ),
>     Entity('Animal',
>            properties = [AString('name', isRequired=1)]
>            )
>     ]
> 
> model.build()
> 
-- 
Lorenzo Gil Sanchez <lg...@si...>

[Modeling-users] problem with the simplest of the model

[Lorenzo G. S. <lg...@si...>]

Hello,

I'm upgrade Modeling with the latest cvs and now, for a very simple
model, the script mdl_generate_DB_schema.py gives me errors:

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

mdl_generate_DB_schema.py -v -C --admin-dsn localhost:pets.sqlite:kk:zz
model_pets2.py
Loading the model...
Error: model has errors:

Aborting

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

As you can see I can't know what is wrong with my model, which I'll
paste right here:


from Modeling.PyModel import *

Entity.defaults['properties'] = [
    APrimaryKey('id', isClassProperty=0, isRequired=1, doc='PK')
    ]

model = Model('Pets', adaptorName='SQLite',
              connDict={'database': 'pets.sqlite'}, version='0.1')

model.entities = [
    Entity('Person',
           properties = [AString('name', isRequired=1)]
           ),
    Entity('Animal',
           properties = [AString('name', isRequired=1)]
           )
    ]

model.build()

-- 
Lorenzo Gil Sanchez <lg...@si...>

[Modeling-users] Scripts now aborting when a model has errors

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

        Hi all,

  I just want to signal that bug #994403 has been fixed, changing the
behaviour of both scripts 'mdl_generate_DB_schema.py' and
'mdl_generate_python_code.py': they now abort when the model contains error=
s,
unless option '-f-'/'--force' is set.

https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D994403&group_=
id=3D58935&atid=3D489335

The new version for the scripts can be downloaded at:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/modeling/ProjectModeling/M=
odeling/scripts/mdl_generate_DB_schema.py?rev=3D1.12
and
http://cvs.sourceforge.net/viewcvs.py/*checkout*/modeling/ProjectModeling/M=
odeling/scripts/mdl_generate_python_code.py?rev=3D1.9


  If you have some time to download them and check that it works as expected
  w/ your own projects, I'll appreciate the reports!

-- S=E9bastien.

Re: [Modeling-users] BR: fetch() doesn't bark on wrong class name

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

Marcos Dione <md...@vi...> wrote:
> User-Agent: Mutt/1.3.28i
>=20
> On Tue, Sep 21, 2004 at 08:17:02PM +0200, Sebastien Bigaret wrote:
> >=20
> > Better late than never... The bug is at last fixed, see
> > https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D916019&gr=
oup_id=3D58935&atid=3D489335
>=20
>     wonderful! unluckly I couldn't help you fix this one. I think I owe
> you a bottle of wine or similar. good work!

Wow, thanks, but wait! :) I only made part of the work.  Incidentally, I've=
 just noticed
that the second part of your original message did not exhibit the same bug:=
 it
is in fact due to qualifierWithQualifierFormat() not detecting some syntax
error, such as in:

   name like "bob" AND isActive=3D1

(it is incorrect: '=3D' is not an operator, but '=3D=3D' is)

  I've just opened a new ticket for this one:
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1032577&group=
_id=3D58935&atid=3D489335

Attached to this ticket is a patch solving it --it would be nice if enough
people could test it w/ their own qualifiers and report that it does not br=
eak
any valid ones, so I can integrate it into the main trunk.

-- S=E9bastien.

Re: [Modeling-users] BR: fetch() doesn't bark on wrong class name

[Marcos D. <md...@vi...>]

User-Agent: Mutt/1.3.28i

On Tue, Sep 21, 2004 at 08:17:02PM +0200, Sebastien Bigaret wrote:
> 
> Better late than never... The bug is at last fixed, see
> https://sourceforge.net/tracker/index.php?func=detail&aid=916019&group_id=58935&atid=489335

    wonderful! unluckly I couldn't help you fix this one. I think I owe
you a bottle of wine or similar. good work!

Re: [Modeling-users] BR: fetch() doesn't bark on wrong class name

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

Better late than never... The bug is at last fixed, see
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D916019&group_=
id=3D58935&atid=3D489335

-- S=E9bastien.


Marcos Dione <md...@vi...> wrote:
>     is simple to reproduce: just call EditingContext.fetch ()  with a
> wrong class name. I got two different errors with two different
> qualifiers, so I thought it was a bad qualifier, and then I realize my
> typo. here are those errors:
>=20
> Traceback (most recent call last):
>   File "/home/mdione/src/papo_project/cimarron/src/Gtk2/Gtk2Button.py", l=
ine 93, in __activate
>     self.submit()
>   File "./Generic/Control.py", line 145, in submit
> Generic.Exceptions.ControlError: No pude guardar el valor en el Modelo:
> ... Traceback (most recent call last):
> ...   File "./Generic/Control.py", line 143, in submit
> ...   File "./Generic/Control.py", line 71, in doAction
> ...   File "/home/mdione/src/papo_project/luca/Forms.py", line 58, in save
> ...     guys=3D ec.fetch ('Person', qualifier=3D'name like "%s"' % self.n=
ameInput.getValue ())
> ...   File "/usr/lib/python2.3/site-packages/Modeling/EditingContext.py",=
 line 1415, in fetch
> ...     fs=3DFetchSpecification(entityName, qualifier=3Dqualifier, deepFl=
ag=3DisDeep)
> ...   File "/usr/lib/python2.3/site-packages/Modeling/FetchSpecification.=
py", line 53, in __init__
> ...     self.setQualifier(qualifier)
> ...   File "/usr/lib/python2.3/site-packages/Modeling/FetchSpecification.=
py", line 108, in setQualifier
> ...     aQualifier.validateKeysWithRootClassDescription(classDescriptionF=
orName(self._entityName))
> ...   File "/usr/lib/python2.3/site-packages/Modeling/Qualifier.py", line=
 177, in validateKeysWithRootClassDescription
> ...     allCDkeys=3DaClassDescription.allAttributesKeys()+\
> ... AttributeError: 'NoneType' object has no attribute 'allAttributesKeys'
[...]

Re: [Modeling-users] possible bug with autorelationships

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

        Hi,

  Sorry for the late answer.

You've found a bug, indeed; however, it's not exactly where we think it
can be at first sight!

  The fact is that we do not support one-to-one relationship directly
for the moment being, see here the instructions for a workaround:
  http://modeling.sourceforge.net/UserGuide/design-rels.html

The error you get is completely due to the fact that a one-to-one isn't
expected there, but this should be treated by something else than an
assert clause.

I've not look closely yet to what happens when you suppress the BaseType
(hence, suppressing the error as well), but I suspect that the model is
not correct.  This needs further investigation, obviously --in any case,
again, the pymodel should be able to report that the one-to-one is not
supported yet.

    Thanks for reporting,

-- S=E9bastien.


Lorenzo Gil Sanchez <lg...@si...> wrote:
> Hi,
>=20
> I have a Person entity and I'm trying to define a relationship between
> two persons. Something like the husband/wife relationship. So far it
> works, the problem is when other classes appear in the inheritance tree.
>=20
> I have a Customer entity which is-a Person, which is-a BaseType. This is
> how my PyModel looks like:
>=20
> from Modeling.PyModel import *
>=20
> Entity.defaults['properties'] =3D [
>     APrimaryKey('id', isClassProperty=3D0, isRequired=3D1, doc=3D'PK')
>     ]
>=20
> _connDict =3D {'database': 'pruebas_modeling.sqlite'}
>=20
> model =3D Model('Pruebas', adaptorName=3D'SQLite', connDict=3D_connDict,
>               version=3D'0.1')
>=20
> model.entities =3D [
>     Entity('BaseType',
>            properties=3D[AFloat('oid', doc=3D'Internal object identifier'=
)]
>            ),
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
>     Entity('Person',
>            properties=3D[AString('name'),
>                        AString('surname'),
>                        ADateTime('birthdate'),
>                        AInteger('employed', defaultValue=3D1),
>                        RToOne('husband', destination=3D'Person',
> inverse=3D'wife'),
>                        RToOne('wife', destination=3D'Person',
> inverse=3D'husband')],
>            parent=3D'BaseType',
>            ),
>     Entity('Customer',
>            properties=3D[AFloat('salary')],
>            parent=3D'Person',
>            ),
>     ]
>=20
> model.build()
>=20
> ------------------------------------------------------
>=20
> If I run that code I get this exception:
> Traceback (most recent call last):
>   File "prueba_autorrelacion.py", line 32, in ?
>     model.build()
>   File "/opt/lib/python2.3/site-packages/Modeling/PyModel.py", line 228,
> in build
>     entity.build_toOne_relationships(self)
>   File "/opt/lib/python2.3/site-packages/Modeling/PyModel.py", line 446,
> in build_toOne_relationships
>     prop.build(model, self)
>   File "/opt/lib/python2.3/site-packages/Modeling/PyModel.py", line 701,
> in build
>     entity.forward_rel_info(self, model)
>   File "/opt/lib/python2.3/site-packages/Modeling/PyModel.py", line 437,
> in forward_rel_info
>     rel.dst,invr.src=3Dcheck_or_make_equal(rel.dst,invr.src)
>   File "/opt/lib/python2.3/site-packages/Modeling/PyModel.py", line 421,
> in check_or_make_equal
>     assert x =3D=3D y
> AssertionError
>=20
>=20
> There are several ways to get rid of the exception:
>=20
> - Remove the Customer entity
> - Make the Person entity don't inherit from BaseType
> - Remove the BaseType entity
>=20
> Obviously none of those is what I want so I wonder if anyone in the list
> knows why my relations are messing the inheritance or viceversa.
>=20
> Thanks
>=20
> Lorenzo Gil Sanchez

[Modeling-users] possible bug with autorelationships

[Lorenzo G. S. <lg...@si...>]

Hi,

I have a Person entity and I'm trying to define a relationship between
two persons. Something like the husband/wife relationship. So far it
works, the problem is when other classes appear in the inheritance tree.

I have a Customer entity which is-a Person, which is-a BaseType. This is
how my PyModel looks like:

from Modeling.PyModel import *

Entity.defaults['properties'] = [
    APrimaryKey('id', isClassProperty=0, isRequired=1, doc='PK')
    ]

_connDict = {'database': 'pruebas_modeling.sqlite'}

model = Model('Pruebas', adaptorName='SQLite', connDict=_connDict,
              version='0.1')

model.entities = [
    Entity('BaseType',
           properties=[AFloat('oid', doc='Internal object identifier')]
           ),
                       
    Entity('Person',
           properties=[AString('name'),
                       AString('surname'),
                       ADateTime('birthdate'),
                       AInteger('employed', defaultValue=1),
                       RToOne('husband', destination='Person',
inverse='wife'),
                       RToOne('wife', destination='Person',
inverse='husband')],
           parent='BaseType',
           ),
    Entity('Customer',
           properties=[AFloat('salary')],
           parent='Person',
           ),
    ]

model.build()

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

If I run that code I get this exception:
Traceback (most recent call last):
  File "prueba_autorrelacion.py", line 32, in ?
    model.build()
  File "/opt/lib/python2.3/site-packages/Modeling/PyModel.py", line 228,
in build
    entity.build_toOne_relationships(self)
  File "/opt/lib/python2.3/site-packages/Modeling/PyModel.py", line 446,
in build_toOne_relationships
    prop.build(model, self)
  File "/opt/lib/python2.3/site-packages/Modeling/PyModel.py", line 701,
in build
    entity.forward_rel_info(self, model)
  File "/opt/lib/python2.3/site-packages/Modeling/PyModel.py", line 437,
in forward_rel_info
    rel.dst,invr.src=check_or_make_equal(rel.dst,invr.src)
  File "/opt/lib/python2.3/site-packages/Modeling/PyModel.py", line 421,
in check_or_make_equal
    assert x == y
AssertionError


There are several ways to get rid of the exception:

- Remove the Customer entity
- Make the Person entity don't inherit from BaseType
- Remove the BaseType entity

Obviously none of those is what I want so I wonder if anyone in the list
knows why my relations are messing the inheritance or viceversa.

Thanks

Lorenzo Gil Sanchez

Re: [Modeling-users] SybaseAdaptorLayer

[Duncan M. <py...@ad...>]

On Sep 12, 2004, at 6:06 AM, Sebastien Bigaret wrote:

>> Anyway, we'll be working on the app and the adaptor through next 
>> week. When
>> I'm ready to send you the code, what method do you prefer?
>
>
> That's great! And I'll be happy to grab the first version of it in the
> Patches section @sf.
>
>   BTW: Something I've already said here but that is not written 
> anywhere
>   else (I should fix this): since I want to keep the copyright status 
> of
>   the framework as clear as possible --so before integrating code into
>   mdl I ask that the contributor either assign the copyright on his
>   contribution to me, or disclaim copyright on it and thus put it in 
> the
>   public domain (if this is a problem, the adaptor can be released as a
>   separate package).

Let me ask the people I am contracting for about this. They are big 
supporters of OSS, so odds are good.

> Now a question: will you (or someone in your team?) continue to work w/
> this adaptor (either on new projects or maintaining that one) after the
> project is installed?  Asking this, because I would prefer that someone
> using the adaptor can take the leadership on it, replying to users,
> addressing specific bugs etc.  Would you be interested?

A qualified interested:

I would be more than willing, however:
1) I have very little experience with Sybase, and
2) The only Sybase access I will have after this project is Sybase 12.5 
(most recent) on Mac OS X.

If folks don't have problems with those and can work with me on issues 
(e.g., educate me on Sybase specifics, as needs arise), I would be 
honored to maintain and assist :-)

duncan

P.S. I apologize for the delay; I just found out they've finished 
building out the parts of the deployment env., and we're ready to 
continue work on site this Friday.

Re: [Modeling-users] SybaseAdaptorLayer

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

        Hi Duncan,

Duncan McGreggor <py...@ad...> wrote:
[...]
> We're on-site today at AOL and I'm testing a SybaseAdaptor on their
> dbserver. We were told linux, but it's actually Solaris that they are
> using. No matter, the sybase py module works just fine (well, more or
> less... you can't call a connection without assigning it it to a variable,
> otherwise python is killed).
>=20
> Anyway, we'll be working on the app and the adaptor through next week. Wh=
en
> I'm ready to send you the code, what method do you prefer?


That's great! And I'll be happy to grab the first version of it in the
Patches section @sf.

  BTW: Something I've already said here but that is not written anywhere
  else (I should fix this): since I want to keep the copyright status of
  the framework as clear as possible --so before integrating code into
  mdl I ask that the contributor either assign the copyright on his
  contribution to me, or disclaim copyright on it and thus put it in the
  public domain (if this is a problem, the adaptor can be released as a
  separate package).

Now a question: will you (or someone in your team?) continue to work w/
this adaptor (either on new projects or maintaining that one) after the
project is installed?  Asking this, because I would prefer that someone
using the adaptor can take the leadership on it, replying to users,
addressing specific bugs etc.  Would you be interested?


-- S=E9bastien.

Re: [Modeling-users] saveChanges() doesn't change globalID

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

Marcos Dione <md...@vi...> writes:
> User-Agent: Mutt/1.3.28i
>=20
> On Fri, Sep 10, 2004 at 12:42:30AM +0200, Sebastien Bigaret wrote:
> >   I mean, if you simply drop the existing ECs and get a brand new one,
> >   then ask it for the Persona() (either from a given fetch qualifier or
> >   from its globalID),=20
>=20
>     note that holding the globalID is the same that using the raw_row.

Yeap! except that gIDs have the minimum amount of information needed to
retrieve objects, while raw rows can have a much bigger memory footprint ;)

> the fetch qualifier wouldn't be useful, as the user could have selected
> the Persona() fron la list (the result of a search). I realize you don't
> know that part of the app yet :)

Ok

>     anyways, the problem is not with from-db instances, but with new
> instances.
>=20
> > I suspect I'm missing something important here --because if you simply
> > want to rollback, then you wouldn't try to (re) add newly inserted
> > objects (PostallAddresses I guess) from the beginning.
>=20
>     maybe, I haven't decided taht part, but forgetting them sounds
> reasonable. for rollbacking limited instances we would prefer to obligue
> the user to save the changes to a previous instance.
>=20
> >   Now, whatever your use-cases are and what is behind, I want to make it
> >   clear that, if this is the bug you're observing, this is a serious one
> >   that should be addressed as quickly as possible.  If you do not have
> >   the time to extract the behaviour but have some code revealing it that
> >   you do not want to disclose on a public list, please email me
> >   privately and we'll work together on making from your experience a
> >   public test revealing the bug.
>=20
>     well, I have code, but it's very buried in my app's code. unluckly I
> don't have the time this weeken to try to untangle a simpler example,
> and I don't know if my code's guilty. can I send you the whole bunch
> (~140k)?

If you can, sure: this would help to have the code triggering the bug at
hand --along with the instructions for reproducing and observing the
bug.

-- S=E9bastien.

Re: [Modeling-users] saveChanges() doesn't change globalID

[Marcos D. <md...@vi...>]

User-Agent: Mutt/1.3.28i

On Fri, Sep 10, 2004 at 12:42:30AM +0200, Sebastien Bigaret wrote:
>   I mean, if you simply drop the existing ECs and get a brand new one,
>   then ask it for the Persona() (either from a given fetch qualifier or
>   from its globalID), 

    note that holding the globalID is the same that using the raw_row.
the fetch qualifier wouldn't be useful, as the user could have selected
the Persona() fron la list (the result of a search). I realize you don't
know that part of the app yet :)

    anyways, the problem is not with from-db instances, but with new
instances.

> I suspect I'm missing something important here --because if you simply
> want to rollback, then you wouldn't try to (re) add newly inserted
> objects (PostallAddresses I guess) from the beginning.

    maybe, I haven't decided taht part, but forgetting them sounds
reasonable. for rollbacking limited instances we would prefer to obligue
the user to save the changes to a previous instance.

>   Now, whatever your use-cases are and what is behind, I want to make it
>   clear that, if this is the bug you're observing, this is a serious one
>   that should be addressed as quickly as possible.  If you do not have
>   the time to extract the behaviour but have some code revealing it that
>   you do not want to disclose on a public list, please email me
>   privately and we'll work together on making from your experience a
>   public test revealing the bug.

    well, I have code, but it's very buried in my app's code. unluckly I
don't have the time this weeken to try to untangle a simpler example,
and I don't know if my code's guilty. can I send you the whole bunch
(~140k)?

>     Thanks for your time!

    thanks for *yours*.

Re: [Modeling-users] SybaseAdaptorLayer

[Duncan M. <py...@ad...>]

On Jul 29, 2004, at 11:55 AM, Duncan McGreggor wrote:

> On Jul 29, 2004, at 4:47 AM, Sebastien Bigaret wrote:
>
>> This is great news and yes, a Sybase adaptor will certainly be useful.
>>
>>   However, sorry, I've never used any sybase db server aither, so I've
>>   no experience to offer.  But we can definitely work together to make
>>   it happen, esp. regarding testing and integrating it into the
>>   framework.
>
> Yeah, neither have I; I'm getting some experienced Sybase folks to 
> work with me on this project and advise on Sybase SQL dialect.
>
>> Integrating a new layer in the framework means that we should be able 
>> to
>> integrate it into the testing units, so we should also be able to 
>> deploy
>> a dedicated db-server on the testing machines.  With respect to these
>> requirements, could you confirm that the testing components are the
>> following?
>>
>>   - Sybase Adaptive Server Enterprise 12.5.2
>>     (http://www.sybase.com/detail?id=1030941)
>>
>>   - Sybase module for Python (python DB API v2.0 compliant)
>>     (http://www.object-craft.com.au/projects/sybase/)
>
> Yes, those are the kind and versions we are using.
>
>> I can only test linux-based configurations; if you plan to use 
>> different
>> components and/or different OSes, could you let us know?
>
> You bet. I will be testing on a SuSE 9.0 box myself. I don't know what 
> flavor of linux the group at AOL uses, but I will find out today at 
> the kickoff meeting. We also have another potential client, and for 
> them we will be putting a Mac OS X Xserver appliance in place for 
> them.
>
>>   Looking forward to download the first draft of a Sybase adaptor ;),

Sebastien,

We're on-site today at AOL and I'm testing a SybaseAdaptor on their 
dbserver. We were told linux, but it's actually Solaris that they are 
using. No matter, the sybase py module works just fine (well, more or 
less... you can't call a connection without assigning it it to a 
variable, otherwise python is killed).

Anyway, we'll be working on the app and the adaptor through next week. 
When I'm ready to send you the code, what method do you prefer?

Talk to you soon,

Duncan


--
Duncan M. McGreggor        mailto:du...@ad...
Systems &                  p 301.698.5032
Applications Engineer      m 301.801.0349
AdytumSolutions, Inc.      http://adytum.us

Re: [Modeling-users] one model, multiple database instances

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

Sorry about the delay in getting back on this. Also, as this discussion=20=

is on a very low priority enhancement, and one that S=E9bastien clearly=20=

does not like, I do not want to belabor the issue too much. But for the=20=

sake of correctness, I will just add a few comments that I hope are=20
relevant.

On Aug 30, 2004, at 10:39 PM, Sebastien Bigaret wrote:
> Mario Ruggier <ma...@ru...> wrote:
> [...]
>>
>>>   The real problem here is that you're gonna have objects=20
>>> corresponding
>>>   different entities, all named Document but living in different
>>>   database. Say you have database DB1 and DB2, you suggest that we=20=

>>> can
>>>   have at runtime objects doc1 and doc2, resp. being object for=20
>>> entities
>>>   Document in DB1 and Document in DB2.
>>>
>>> Now you'll see the real problem if you realize that each object is
>>> uniquely identified by its GlobalID.  And a GlobalID is the=20
>>> combination
>>> od an entity name and its PK value(s).  If obj1 and obj2 and the =
same
>>> PK, then they will get the same gID.
>>
>> But, is this simply a matter of changing the algorithm of how a GID =
is
>> calculated?
>> What if you throw in for example the database name as part of that
>> calculation?
>> Then, two objects may have the same entity name, same model name,=20
>> same PK
>> even... but if they come from a different db, there will not be any
>> ambiguity... Note that this should also allow for the possibility to=20=

>> have
>> the same object from the same database but in two distinct=20
>> EditingContexts
>> (not one that inherits from the other), to be correctly identified by=20=

>> the
>> framework as the same object.
>
> If by "database name" you mean adaptor name + db name + user name
> (Oracle for example can handle two db with the same name for two
> different users), then yes, in theory this works.

I guess "database name" will have to be equivalent to the conn=20
dictionary, and mapped down to a single database instance, however that=20=

might be handled by the underlying db.


>>> The consequences are, as expected,
>>> devastative: snapshots are all mixed up, faults will pick up from=20
>>> the db
>>> cache some data that in fact belongs to another database, etc...
>>>
>>>   In brief: your suggestion requires that the entities' names live=20=

>>> in a
>>>   separate namespace, or put differently, that an entity is=20
>>> identified by
>>>   its name and its model's name.
>>
>> Yes, entities' names should be in a different namespace... but, I=20
>> would go
>> even further, and suggest also that models live in a separate=20
>> namespace,
>> defined by the database instance. Thus, you can instantiate the same=20=

>> model
>> **exactly**, but bound to different databases.
>
> Again, in this case, yes, this would work.  But this requires a lot of
> changes.  And back to reality, I believe that:
>
> 1. Any app. that would require/benefit from such a feature can anyhow
>    solve the problem differently and without much trouble,

I can appreciate that the framework change may not be feasible at all,=20=

and that workarounds are available. My concern though is primarily to=20
simplify and improve how the framework can be used. It is (kind of ;)=20
like saying that there is no need to make a piece of code clearer=20
because it works...


> 2. this would add either some heavy changes in the API or some sort of
>    "implicit" knowledges about the EC e.g. for some operations. For
>    example: would we require that ec.fetch() specifies the exact =
Entity
>    object (or an equivalent string, with the whole conn.dicyt =
(possibly
>    hashed)?  Or would we rather consider by default the model to which
>    the EC is bound, making the portion of code::
>
>         ec.fetch('Person')
>
>    fuzzy about which Entity it fetches?

I am not sure I understand your first point here. I was assuming=20
something along the lines of the second one, that is:
- an EC instance *must* be initialised with a Model instance, and a=20
ConnDict
- each object in the EC corresponds to a Type (from the model) and a=20
table row in the db identified by the conndict
- if a second EC is initialiased in the same way, then if the same=20
object is loaded in either of these two ECs, it will have the same gid.
- nested ECs must assume the same model and conndict of the parent EC

Thus, except for the difference in EC initialisation, I do not see why=20=

the API should change at all... at least the exposed API, as internally=20=

there may well be major issues that I am not even considering.


>> [...] I want to understand better if the idea makes any sense, if
>> having such a way of initialising an EC brings other advantages or
>> disadvantages, and how difficult it is to modify the framework so
>> drastically.
>>
>> I cannot appreciate how much work such a thing could be, but from =
what
>> you say above I suspect it may be less than I thought ;)
>>
>> In any case, I think it would be too early to add this as a TODO item
>> as yet, as further poking and contemplation is probably a good
>> idea. Anyone else following this issue have an opinion?
>
> You're right, that's way too early!...  As you probably already=20
> guessed,
> the more I'm thinking about such an extension, the less I like it.  =
The
> concepts is simple, but the consequences, esp. on the API, are not
> desirable at all.  I believe that asking more than an Entity to be
> supplied to e.g. ec.fetch() is not a very good idea, and I do not like
> the idea of adding the level of implicit described above in statements
> like ec.fetch().  Makes sense?

Again, I do not get this point, i.e. why do you need to specify more=20
than the Entity to ec.fetch() ? The ec instance itself knows what the=20
context of the fetch is, and that is the model instance plus the=20
conndict it was initialised with. The fetch interface should not change=20=

at all.... but, I think I may be missing something here!

> -- S=E9bastien.


Cheers, mario

Re: [Modeling-users] saveChanges() doesn't change globalID

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

Marcos Dione <md...@vi...> wrote:
>     the usage of this rollbackable thing is to develop a=20=20=20=20=20=
=20=20=20
>     insert-modify-delete part of a bigger application. the user can be=20=
=20=20=20
>     handling only one instance at a time, but this instance could have
>     several other instances of other (or the same) related to it, and
>     being edited at the same time.
>=20
>     e.g, here we have a Persona() entity, related with several
>     PostalAddr(). the user can be editing only one Persona, but several
>     (all the related ones) PostalAddr. the rollback mechanisms throws
>     away the ec, and repopulates starting from the Persona, so the
>     rollback applies to the persona and its related objects. maybe later
>     we'll add support for rollbacking individual PostalAddr's.

Given this, and what you say about new objects (simply calling the
constructor), I wonder why you need to explicitly track the rollback
thing.

  I mean, if you simply drop the existing ECs and get a brand new one,
  then ask it for the Persona() (either from a given fetch qualifier or
  from its globalID), and then its postal addr. with
  person.getPostalAddresses(), then you instantly get what is in the db
  --no need to keep raw rows under the pillow, just because an EC is in
  fact a transaction at the object level: until you saveChanges(), the
  changes are not persistent and there's nothing to do to retrieve the
  objects as they are stored in the db.

I suspect I'm missing something important here --because if you simply
want to rollback, then you wouldn't try to (re) add newly inserted
objects (PostallAddresses I guess) from the beginning.  This probably
means that you want to rollback some changes, while keeping newly
inserted objects, and maybe(?) how relationships between newly inserted
and 'from-db' objects were modified.  Sorry if I did not understand you
right, again a sample code might help, showing what happens before a
rollback, and what you want to get after the custom rollback happens.

> >   If what you see is newly inserted objects not getting their
> >   corresponding KeyGlobalID after ec.saveChanges(), but keeping their
> >   old TemporaryGlobalID instead, this is definitely a bug, and a serious
> >   one, and I'm very interesting in seeing the code triggering it.
>=20
>     good, this seems to be the thing happening.

  Now, whatever your use-cases are and what is behind, I want to make it
  clear that, if this is the bug you're observing, this is a serious one
  that should be addressed as quickly as possible.  If you do not have
  the time to extract the behaviour but have some code revealing it that
  you do not want to disclose on a public list, please email me
  privately and we'll work together on making from your experience a
  public test revealing the bug.

    Thanks for your time!

-- S=E9bastien.
=20=20





Marcos Dione <md...@vi...> wrote:
> On Thu, Sep 09, 2004 at 12:41:11PM +0200, Sebastien Bigaret wrote:
> > >     given a EditingContext, there a re two kind of objects registered=
 at
> > > the moment fo saveChanges(): from-database ones (globalID() is an
> > > instance of KeyGlobalID), and new ones (globalID() is an instance of
> > > TemporaryGlobalID). when I roll back, I do the following:
> > >=20
> > > * 'hold' the model: any from-database object gets hold by means of
> > > snapshot_raw(). new ones are simply forgoten.
> > >=20
> > > * build a new EditingContext.
> > >=20
> > > * repopulate it with the old objects. from-database ones get reinsert=
ed
> > > via faultForRaw(), and new ones simply requesting a new instance of t=
he
> > > proper class.
> >=20
> > Could you be a little more explicit about the use cases behind this
> > rollback mechanism?=20
>=20
>     I'll try :) the general idea is to be able to get the previous state
> of any object inserted in the ec. this previous state for from-db
> instances is the state in the db, that's why I foult them and then let
> Modeling refetch the values on any reference to any of its attributes.
> for new ones, it would be an empty model, like the one get w/ just
> calling the proper constructor. e.g., say I have a Persona entity, an
> empty model is the result of calling Persona().
>=20
> > Are "from-db objects" changed within the EC?
>=20
>     could be. a rollback must revert their properties' values to the ones
> in the db.
>=20
> > Or do
> > you simply want to remove the inserted ones,=20
>=20
>     as the way I sue it, you can't add several empty instances, so a
> rollback after modifing it just gives me an empty model again. also, no
> more that one model can be handled at the same time.
>=20
>     the usage of this rollbackable thing is to develop a=20=20=20=20=20=
=20=20=20
>     insert-modify-delete part of a bigger application. the user can be=20=
=20=20=20
>     handling only one instance at a time, but this instance could have
>     several other instances of other (or the same) related to it, and
>     being edited at the same time.
>=20
>     e.g, here we have a Persona() entity, related with several
>     PostalAddr(). the user can be editing only one Persona, but several
>     (all the related ones) PostalAddr. the rollback mechanisms throws
>     away the ec, and repopulates starting from the Persona, so the
>     rollback applies to the persona and its related objects. maybe later
>     we'll add support for rollbacking individual PostalAddr's.
>=20
> > and to revert the
> > persistent ones to the state they have in the db?
>=20
>     yeap.
>=20
> > Plus, when you say you repopulate the new EC with the new ones, how is
> > this done?
>=20
>     o=3D Persona ()
>     ec.insert (o)
>=20
>     (more or less)
>=20
> >   If what you see is newly inserted objects not getting their
> >   corresponding KeyGlobalID after ec.saveChanges(), but keeping their
> >   old TemporaryGlobalID instead, this is definitely a bug, and a serious
> >   one, and I'm very interesting in seeing the code triggering it.
>=20
>     good, this seems to be the thing happening.
>=20
> >   More details in case you're interested and you want to investigate
> >   this: changing newly inserted objects gIDs is done at the very end of
> >   the saveChanges() process, and DBContext.finalizeCommitChanges() is
> >   responsible for this. It broadcasts a GlobalIDChangedNotification,
> >   handled by ec.handleNotification() (among other possible observers)
> >   which in turn re-registers the object with its newly assigned
> >   KeyGlobalID.
>=20
>     good! I'll try to see it now and post any clues later.

Re: [Modeling-users] saveChanges() doesn't change globalID

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

Marcos Dione <md...@vi...> wrote:
> User-Agent: Mutt/1.3.28i
>=20
> On Thu, Sep 09, 2004 at 12:41:11PM +0200, Sebastien Bigaret wrote:
> >   More details in case you're interested and you want to investigate
> >   this: changing newly inserted objects gIDs is done at the very end of
> >   the saveChanges() process, and DBContext.finalizeCommitChanges() is
> >   responsible for this. It broadcasts a GlobalIDChangedNotification,
> >   handled by ec.handleNotification() (among other possible observers)
> >   which in turn re-registers the object with its newly assigned
> >   KeyGlobalID.
>=20
>     according to the comments in ec.handleNotification(), the PK is not
> changed to a GlobalID until then, so I can assume that code isn't
> reached, so maybe an exception is trown earlier. I'll try to find it
> tomorrow (now I gotta run to another job).

  Okay, if you do not have much time you cannot investigate it any
deeper --but still, a portion of code exhibiting the problem (as opposed
to: diagnosing the problem) could be enough, so just send it as-is if
you have it :)

>     I also saw a few debug(), warn() and trace() callings, and found
> their declaration in logging.py. should I assign log_stderr to them so
> they show something? I see that no_log can receive a severity param, but
> log_stderr doesn't. should I fix that?

Nope. If you want to activate all message simply replace the line
saying:
    trace=3Ddebug=3Dinfo=3Dlog=3Dwarn=3Derror=3Dfatal=3Dno_log
with:
    trace=3Ddebug=3Dinfo=3Dlog=3Dwarn=3Derror=3Dfatal=3Dlog_stderr

and set MDL_ENABLE_DATABASE_LOGGING to '1'.


-- S=E9bastien.

Re: [Modeling-users] saveChanges() doesn't change globalID

[Marcos D. <md...@vi...>]

User-Agent: Mutt/1.3.28i

On Thu, Sep 09, 2004 at 12:41:11PM +0200, Sebastien Bigaret wrote:
>   More details in case you're interested and you want to investigate
>   this: changing newly inserted objects gIDs is done at the very end of
>   the saveChanges() process, and DBContext.finalizeCommitChanges() is
>   responsible for this. It broadcasts a GlobalIDChangedNotification,
>   handled by ec.handleNotification() (among other possible observers)
>   which in turn re-registers the object with its newly assigned
>   KeyGlobalID.

    according to the comments in ec.handleNotification(), the PK is not
changed to a GlobalID until then, so I can assume that code isn't
reached, so maybe an exception is trown earlier. I'll try to find it
tomorrow (now I gotta run to another job).

    I also saw a few debug(), warn() and trace() callings, and found
their declaration in logging.py. should I assign log_stderr to them so
they show something? I see that no_log can receive a severity param, but
log_stderr doesn't. should I fix that?

Re: [Modeling-users] saveChanges() doesn't change globalID

[Marcos D. <md...@vi...>]

User-Agent: Mutt/1.3.28i

On Thu, Sep 09, 2004 at 12:41:11PM +0200, Sebastien Bigaret wrote:
> >     given a EditingContext, there a re two kind of objects registered at
> > the moment fo saveChanges(): from-database ones (globalID() is an
> > instance of KeyGlobalID), and new ones (globalID() is an instance of
> > TemporaryGlobalID). when I roll back, I do the following:
> > 
> > * 'hold' the model: any from-database object gets hold by means of
> > snapshot_raw(). new ones are simply forgoten.
> > 
> > * build a new EditingContext.
> > 
> > * repopulate it with the old objects. from-database ones get reinserted
> > via faultForRaw(), and new ones simply requesting a new instance of the
> > proper class.
> 
> Could you be a little more explicit about the use cases behind this
> rollback mechanism? 

    I'll try :) the general idea is to be able to get the previous state
of any object inserted in the ec. this previous state for from-db
instances is the state in the db, that's why I foult them and then let
Modeling refetch the values on any reference to any of its attributes.
for new ones, it would be an empty model, like the one get w/ just
calling the proper constructor. e.g., say I have a Persona entity, an
empty model is the result of calling Persona().

> Are "from-db objects" changed within the EC?

    could be. a rollback must revert their properties' values to the ones
in the db.

> Or do
> you simply want to remove the inserted ones, 

    as the way I sue it, you can't add several empty instances, so a
rollback after modifing it just gives me an empty model again. also, no
more that one model can be handled at the same time.

    the usage of this rollbackable thing is to develop a        
    insert-modify-delete part of a bigger application. the user can be    
    handling only one instance at a time, but this instance could have
    several other instances of other (or the same) related to it, and
    being edited at the same time.

    e.g, here we have a Persona() entity, related with several
    PostalAddr(). the user can be editing only one Persona, but several
    (all the related ones) PostalAddr. the rollback mechanisms throws
    away the ec, and repopulates starting from the Persona, so the
    rollback applies to the persona and its related objects. maybe later
    we'll add support for rollbacking individual PostalAddr's.

> and to revert the
> persistent ones to the state they have in the db?

    yeap.

> Plus, when you say you repopulate the new EC with the new ones, how is
> this done?

    o= Persona ()
    ec.insert (o)

    (more or less)

>   If what you see is newly inserted objects not getting their
>   corresponding KeyGlobalID after ec.saveChanges(), but keeping their
>   old TemporaryGlobalID instead, this is definitely a bug, and a serious
>   one, and I'm very interesting in seeing the code triggering it.

    good, this seems to be the thing happening.

>   More details in case you're interested and you want to investigate
>   this: changing newly inserted objects gIDs is done at the very end of
>   the saveChanges() process, and DBContext.finalizeCommitChanges() is
>   responsible for this. It broadcasts a GlobalIDChangedNotification,
>   handled by ec.handleNotification() (among other possible observers)
>   which in turn re-registers the object with its newly assigned
>   KeyGlobalID.

    good! I'll try to see it now and post any clues later.