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

Re: [Modeling-users] Limit

[Jerome K. <Jer...@fi...>]

On Fri, Feb 21, 2003 at 04:24:53PM +0100, Sebastien Bigaret wrote:

One of my favorite game, awking dead thread :) 

Apologize for this long time answer. 


> > Limit to a fixed maximum number? Don't think you can (for Sebastien to
> > confirm) unless there is hidden support for specifying TOP N on SELECTs
> > (which i think is not standard SQL?). And, how would you get the next batch
> > then?
> 
>   Sorry soif, Mario's right... there's currently no way to limit or batch
>   the fetch. However EditingContext.objectsCountWithFetchSpecification()
>   will tell you how many objects (in fact, the upper limit) you'll get if
>   you send the same parameters to objectsWithFetchSpecification().

Yes in fact, i ever know this. 
 
>   More on this: if someone knows some standard SQL for doing this, I'm
>   interested, it would for sure make the release-time for such a feature,
>   if requested, closer than it actually is.


After some googling, i found nothing. In fact 'LIMIT' is a SQL92
keyword, but i found nowhere the SQL92 def of this :( , anyways i
use it on a couple of DB before and i 've never see something that
doesn't support it. 


Bye Bye .. :) 

== 

Re: [Modeling-users] Pythonic, and non-XML, Model description

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 26 February 2003 03:28 pm, Sebastien Bigaret wrote:
> Would you mind sharing your conversion scripts from db-designer to
> xml-modeling? I'm thinking of adding a few notes on this tool in the
> framework's documentation, and having the conversion script would be
> really handy.

The script is really sketchy at the moment with a lot of default
values hard-coded but it would not be hard to modularize it enough to
make it useful for the general public.

I let you look at it, tell me how we could make it more general and
I'll see what we can do.

Fell free to ask questions about the implementation.

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+Xh/orhy5Fqn/MRARAtilAJ4hyfFM/WBv813kkLd7LyvC+FqShwCdFeIl
mwraNTZ++vl/QD65S9c0hhY=
=Y/SP
-----END PGP SIGNATURE-----

Re: [Modeling-users] Pythonic, and non-XML, Model description

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

        Hi,

  A quick notes about that:

> > Can you please take a look at the attached 2 files;
> > PyModel.py -- defines the classes (signatures for) for, and documen=
ts
> > the rules for, a PyModel instance
> > sample_PyModel.py -- re-expresses the StoreEmployees model
>=20
> One thing that is a big win for Modeling is the ability to import a X=
ML
> model.  We make our models with Data Designer
> (http://www.danny.cz/datadesigner.en.html) and convert the XML to a f=
ormat
> that Modeling can easily crunch.  The performance boost of the python
> model is a big win but the ability to import, convert, compile, ... a=
 XML
> model should be kept.
>=20
> I mean, we'd like to see it in future releases.=20

As Mario already said, there's nothing to worry about. Moreover, this i=
s a
very valuable information that you gave us ; I did not succeed in linki=
ng
the db schema designer yet /: (I get a bunch of warnings about wx stuff
being undefined references) but the screenshots make me think it might =
me a
modeler really worth a try. It might be the modeler I'm looking for.

  Would you mind sharing your conversion scripts from db-designer to
  xml-modeling? I'm thinking of adding a few notes on this tool in the
  framework's documentation, and having the conversion script would be
  really handy.

I also agree with Mario saying that two (or more!) different models can
co-exist with no problem. That said it is possible that a python model,=
 if
defined, will be preferred for run-time initialization (loading the mod=
el)
since it is likely to load far quicker than parsing the xml... Whatever
the changes, you can count on a bridge between the model formats.

  Last: Mario, I have not found the time yet to study your proposal but=
 I
  will for sure.

        Cheers,

-- S=E9bastien.

Re: [Modeling-users] Pythonic, and non-XML, Model description

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

Hello Yannick,

thanks for the remark. I think there is nothing to worry about here -- 
the
XML model is not likely to ever disappear... and even if some other 
model
might eventually be preferred for the runtime, whatever that model will 
be
it will be easy to have a to-and-fro transform between it and the XML.

Cheers, mario


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 24 February 2003 17:57, Mario Ruggier wrote:
>> Can you please take a look at the attached 2 files;
>> PyModel.py -- defines the classes (signatures for) for, and documents
>> the rules for, a PyModel instance
>> sample_PyModel.py -- re-expresses the StoreEmployees model
>
> One thing that is a big win for Modeling is the ability to import a 
> XML model.
> We make our models with Data Designer
> (http://www.danny.cz/datadesigner.en.html) and convert the XML to a 
> format
> that Modeling can easily crunch.  The performance boost of the python 
> model
> is a big win but the ability to import, convert, compile, ... a XML 
> model
> should be kept.
>
> I mean, we'd like to see it in future releases.
>
>  : )
>
> Regards,
>
> - --
> Yannick Gingras
> Coder for OBB : Offstage Broad-headed Bitterweed
> http://OpenBeatBox.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
>
> iD8DBQE+W15Yrhy5Fqn/MRARAruzAJsH9Glm0bOfo1tsXhQ3attFh4S/cwCdE5V9
> lyHNxLYYsp4vMSqD1xbVnDE=
> =OHo7
> -----END PGP SIGNATURE-----
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Modeling-users mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modeling-users

Re: [Modeling-users] Pythonic, and non-XML, Model description

[Yannick G. <ygi...@yg...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 24 February 2003 17:57, Mario Ruggier wrote:
> Can you please take a look at the attached 2 files;
> PyModel.py -- defines the classes (signatures for) for, and documents
> the rules for, a PyModel instance
> sample_PyModel.py -- re-expresses the StoreEmployees model

One thing that is a big win for Modeling is the ability to import a XML model.  
We make our models with Data Designer 
(http://www.danny.cz/datadesigner.en.html) and convert the XML to a format 
that Modeling can easily crunch.  The performance boost of the python model 
is a big win but the ability to import, convert, compile, ... a XML model 
should be kept.

I mean, we'd like to see it in future releases. 

 : )

Regards, 

- -- 
Yannick Gingras
Coder for OBB : Offstage Broad-headed Bitterweed
http://OpenBeatBox.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+W15Yrhy5Fqn/MRARAruzAJsH9Glm0bOfo1tsXhQ3attFh4S/cwCdE5V9
lyHNxLYYsp4vMSqD1xbVnDE=
=OHo7
-----END PGP SIGNATURE-----

Re: [Modeling-users] Pythonic, and non-XML, Model description

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

        Hi,

  Please excuse the re-sent message with attached files -- I did not see
  that Mario found an other way to share its files and I approved its
  former post real too quickly. *My fault*, not his, I guess I should
  not do any administrative tasks before being completely waken up :/

  However I need to review sourceforge's policy to check whether posts
  that are bigger than 40Kb are strongly advised against, and advertised
  as such ; if receiving such a big post really annoys/annoyed you,
  please email & flame me directly.

    My apologies to all, again.

-- S=E9bastien.

[Modeling-users] Pythonic, and non-XML, Model description

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

Hello,

following comments about the XML model (on and off the list) and
how it can be improved or redone altogether, i started thinking about 
it...
And (to be able to get it out of my mind and get to some other work ;-)
here is a proposal for a pure python description of the model. It 
follows
the XML closely, and in fact may always retain compatibility (at least
generation of XML from the python model, which will be trivial).

The behaviour in gnereal would stay the same as the XML way of
doing things, namely form this model you would generate the classes
and the db schemas.

Some differences are choice of default values, and that key and locking
attributes are defined on attributes and relations rather than entities 
;)

As an exercise, I have taken the sample model in the distribution:
testPackages/StoreEmployees/model_StoreEmployees.xml
and re-expressed it in this pythonic way. Apart from readability and
losing of some verbosity, other gains are "executability" and
dynamicity -- it could be very easy to modify a model at runtime, if
you would ever want to do that. Also, given that a model now becomes
a module in and of itself, it gains from what modules have to offer,
such as self-tests. And, speed of course, as i see no reason why
this model object would also not serve as the model object in memory
at runtime (but that's for Sebastien to confirm) -- thus loading the
model is equivalent to "from MyModel import model".

Can you please take a look at the 2 linked files below (as temporary
URLs, as to attach they are too big);
- PyModel.py -- defines the classes (signatures for) for, and
documents the rules for, a PyModel instance
- sample_PyModel.py -- re-expresses the StoreEmployees model

What does everyone think?

mario

http://ruggier.dyndns.org:8080/PyModel/PyModel.py
http://ruggier.dyndns.org:8080/PyModel/sample_PyModel.py

[Modeling-users] Pythonic, and non-XML, Model description

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

Hello,

following comments about the XML model (on and off the list) and
how it can be improved or redone altogether, i started thinking about 
it...
And (to be able to get it out of my mind and get to some other work ;-)
here is a proposal for a pure python description of the model. It 
follows
the XML closely, and in fact may always retain compatibility (at least
generation of XML from the python model, which will be trivial).

The behaviour in gnereal would stay the same as the XML way of
doing things, namely form this model you would generate the classes
and the db schemas.

Some differences are choice of default values, and that key and locking
attributes are defined on attributes and relations rather than entities 
;)

As an exercise, I have taken the sample model in the distribution:
testPackages/StoreEmployees/model_StoreEmployees.xml
and re-expressed it in this pythonic way. Apart from readability and
losing of some verbosity, other gains are "executability" and
dynamicity -- it could be very easy to modify a model at runtime, if
you would ever want to do that. Also, given that a model now becomes
a module in and of itself, it gains from what modules have to offer,
such as self-tests. And, speed of course, as i see no reason why
this model object would also not serve as the model object in memory
at runtime (but that's for Sebastien to confirm) -- thus loading the
model is equivalent to "from MyModel import model".

Can you please take a look at the attached 2 files;
PyModel.py -- defines the classes (signatures for) for, and documents
the rules for, a PyModel instance
sample_PyModel.py -- re-expresses the StoreEmployees model

What does everyone think?

mario

Re: [Modeling-users] Name for methods valueForKey and takeValueForKey?

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

Mario Ruggier <ma...@ru...> writes:
> Hi,
>=20
> i find these names unclear, and even disturbing \-;

  Oh, really, disturbing?

> Should it ever be possible to change them,=20

  It is possible, yes ;)

> and if these names should avoid using 'get' and 'set' not to clash wi=
th
> dedicated getters and setters, then, instead of:
>=20
> valueForKey 		valueForKeyPath
> takeValueForKey   	takeValueForKeyPath
>=20
> I can suggest names such as:
>=20
> retrieveKeyValue 	retrieveKeyPathValue
> assignKeyValue   	assignKeyPathValue
>=20
> or
>=20
> valueFromKey		valueFromKeyPath
> valueForKey		valueForKeyPath
>=20
> or, more consistently, if we reserve the attribute names
> valueByKey and valueByKeyPath:
>=20
> getValueByKey	getValueByKeyPath
> setValueByKey		setValueByKeyPath

Among all these propositions, my preference would go for the last one
(get/setValueByKey) --but I'm not an native english speaker so it's a m=
atter
of taste rather than a matter of linguistics. I also like assign/retrie=
ve,
but this time the inversion of the words (KeyValue vs. ValueForKey) does
disturb me!

> or, even simpler and more elegant (but need extra check per call)
> is to just have the following two methods (reserving attribute name
> keyValue), and determine dynamically whether key specified is
> a simple key or a path (check for '.' should be enough?)
>=20
> getKeyValue=09=09
> setKeyValue

Definitely, yes! This would be more pythonic --I've said that to myself=
 more
than one time. And I can explain why I have not done it yet: the framew=
ork's
core consumes a lot of simple KVC (lots of keys, very few keypaths), and
adding a check here would imply more cpu. However, there's nothing
preventing us from keeping these methods, named (take)valueForKey by no=
w,
for the framework's internal usage and offering the users a more pleasa=
nt
API.

(BTW do you have the same feelings against (take)StoredValueForKey?)


  All in all, this is simply a matter of users' request. Let me know wh=
at
  you all think about it.


        Cheers,

-- S=E9bastien.

[Modeling-users] [Core] Release 0.9pre2

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

        Hi all,

  At last, it is there! It contains important bug-fixes, plus the
  implementation of feature request "Nested EditingContexts" #617997:
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D617997&gr=
oup_id=3D58935&atid=3D489338

This feature makes it possible to have ``sessions''/transactions within
the object world itself: a nested EditingContext would either commit or
cancel a set of changes to its parent, in a transactional way. This
brings 3 of the ACID properties available at the object level:
Atomicity, Consistency and Isolation.

  This is 0.9pre2, not 0.9, because:

  1. while committing the changes I noticed that two bugs might exist in
     a very specific situation --i.e. when an object is inserted then
     deleted in an EC, provided that ec.saveChanges() is not called in
     the meantime. These have never been triggered in real-life
     applications I know ; however I need to write tests and fix them
     before 0.9

  2. The documentation for nested editing contexts still has to be
     written. In the meantime, you can refer to
     tests/test_EditingContext_ParentChild.py for example of use.

This release is in production for about 4 months, and it has been
observed that it is stable --I will also document the exact
configurations for the applications in production along w/ 0.9.

  Please read carefully the changelog, it contains important
  informations, such as the modification of the behaviour of
  EditingContext.objectsWithFetchSpecification().

Last, you'll now find the API for Modeling and Notification frameworks
on the w3site http://modeling.sf.net, generated by epydoc.


        Best regards,


-- S=E9bastien.


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

0.9-pre-2 (2002/02/23)
---------

  This release is known to be stable in two different production
  environments for about 4 months now. Full description of these
  environments will be publicly released with v0.9.

  * Feature Request #617997: "Nested EditingContexts"

    Added/Implemented: isaChildOf(), saveChangesInEditingContext()

    Modified: faultForGlobalID(), initializeObject()

    Documentation for this feature will be available when 0.9 is
    released. In the meantime users can refer to
    tests/test_EditingContext_ParentChild.py for example of use.

  While committing the changes I noticed that two bugs might exist in a
  very specific situation --i.e. when an object is inserted then deleted
  in an EC, provided that ec.saveChanges() is not called in the
  meantime. See the announce on sourceforge's mailing-list for more
  details.

0.9-pre-1 (2002/02/23) Project milestone, CVS-tagged but no public tarb=
all
---------

  * EditingContext and related changes in DatabaseContext:
                             [committed in EC v1.15 and DBContext v1.13]

    - Fixed deleteObject(): it failed when called on an previously
      inserted object (inserted, but not saved): 1. _insertedObjects was
      not examined, only _pendingInsertedObjects, and 2. deleting an
      inserted object wrongly registered it in the list of deleted
      objects, instead of simply forgetting it.

    - Updated docstrings for (all)inserted/updated/deletedObjects()

    - Changed: objectsWithFetchSpecification(): the result set now
      includes inserted objects even if they have not been saved yet ;
      it also does not include any more the objects that have been
      marked for deletion. This makes this method reflect the changes
      made in the EditingContext rather than the sticking to the
      database state.

      Similarly, DatabaseContext.objectsWithFetchSpecification() does
      NOT take anymore about deleted objects in the calling editing
      context. This participates of the same logic: a DBContext has no
      internal state and should not be aware of any changes made in an
      ObjectStore somewhere higher in the ObjectStore hierarchy.

      cf.: test_01b_objectsWithFetchSpecification_and_insertObject in
           test_EditingContext_Global

    - GlobalIDChangedNotification is now correctly used for notifying
      observers that an inserted object as been saved, thus has received
      a KeyGlobalID in remplacement for its TemporaryGlobalID.

      Changes made in:

        - EC.recordChanges(): register the EC as an observer
        - EC.handleNotification()
        - DatabaseContext.finalizeCommitChanges() posts the
            notification, when appropriate, instead of doing the real
            job on behalf of the EC.

     - Implemented: ownsObject()


  * CustomObject: fixed snapshot(): now raises ObjectNotRegisteredError
      when the object is not registered in an EditingContext, or if at
      least one of the objects it is in relation w/ is not known to the
      object's EC.

      + Implemented: updateFromSnapshot()

  * doc/

    + HomePage: removed the frames and replaced them with a html table

    + Added API for Modeling and Notification (online+tarballs),
      generated by epydoc

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

Re: Constraining primary keys (was: [Modeling-users] primary key + class property)

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

        Hi,

> > - you have some tables, say T1, T2 and T3, for which you want to ha=
ve a
> >   unique pk-generation scheme, i.e. where a pk value in T1 cannot b=
e a
> >   pk value in t2 and in t3
>
> Exactly.

Okay, let's consider they are all sub-entities of entity Node

> [...] i tend to think of these relations being always of type
> dataTable-to-indexTable. Thus, indexTable rows are really not aware of
> what they point to (or rather, who is pointing to them) -- except,
> obviously, that one would be able to navigate from an indexTable row
> to a dataTable row, even without explicit outgoing relationships on
> the indexTable, facilitated by the fact that the primaryKey are
> identical. However, from the dataTable end, each table provides an
> explicit relationship into any desired indexTable, helping enforce
> that the management of a data row's index entry "belongs" to the data
> row, i.e. the logic to add or delete a data row will include the logic
> to add or delete (or modify) all affected index entries.
>
> Example:
>
> NODE      an index table
> id:           int pk
> name:         str
> type: enum : A | B | C  (defined via some rel to another TYPE table,
>                          thus adding possibility to specify
>                          some meta-data for each type, e.g; an icon)
>
> TREE  index imposes a hierarchy on NODE rows
> treeId:       int pk
> parent        rel to Node.pk
> child         rel to Node.pk
>
> A
> id:           int pk
> a1
> a2
> toNode        explicit relation to Node, and with A.id =3D Node.id
>
> similarly for B and C
>
> How would be best to model such a structure?

  My first thought about this is that the underlying model might look l=
ike:

[1]    +-children----+
       |             |
       v             |
       v             |
    +------+         |
    | Node |<-parent-+
    +------+=20=20=20=20=20=20=20=20=20=20
       |
    +--+--+
    |  |  |
    A  B  C

which can be modeled just straightforward. However I suspect that your
situations requires to keep the hierarchy structure separated from the
informations stored in table A, B and C. In this case, I guess you may
consider this model:

[2]                             +--children---+
                                |             |
                                v             |
                                v             |
    +------+                 +------+         |
    | Node |<-node-----tree->| Tree |<-parent-+
    +------+                 +------+
       |
    +--+--+
    |  |  |
    A  B  C


Given that one-to-one is not supported yet, the node/tree relationship
must be modeled as a one-to-many rel. If you really do not want to have
*any* informations in tables A, B and C about the tree structure (that
is to say, that's a requirement at the relational level, nnot on the
objects' side), just design the toNode as to-one and toTree as to-many
(this way, the relationship is retrieved via a foreign key declared in
the table Tree)


  However and re-reading your post, the following things seem strange t=
o me:

> NODE
> type: enum : A | B | C  (defined via some rel to another TYPE table,
>                          thus adding possibility to specify
>                          some meta-data for each type, e.g; an icon)
[...]
> A:
> toNode        explicit relation to Node, and with A.id =3D Node.id

I wonder whether you're not too tight to the way you'll do this by hand
with raw SQL, or if I'm missing something. Let me comment on this:

   You say A.id=3DNode.id, but you'll never get this: the framework mak=
es
   sure that each row of Node (which will in fact be an empty table,
   since no elements of type Node would ever be instanciated), A, B or C
   will have different PK. In the case you think of it as a mean to
   actually retrieve the corresponding object pointed to in either A, B
   and C, you do not need it: the framework automatically takes care of
   this for you. E.g. in [1], parent & children relationships can point
   to objects of type A, B or C (same for toNode in [2]).

Same for the other entity Type: just model it the way the association
between Node & Tree is made in [2] (or alternatively put the common
meta-datas in entity Node and specific metadatas in entities A, B & C
--at least if the set of metadatas are not subject to changes after
valuable datas are stored within the database: if they are, the first
solution is a better one for sure).

> Ah, i did not realise that inheritance enforces that pk's are unique
> across all rows in the inheritance tree! In the above example, then,
> would it be enough to make A, B and C inherit from NODE?=20

I think so

> (This also raises the question whether the limitation mentioned in the
> manual in section 2.3.2 is still valid... namely that "that toMany
> relationships must have inverse (toOne) relationships defined in the
> model".)

Yes, indeed, this is still valid.

> I am looking for a way to implement the example construct above, while
> staying as light as possible (minimum number of explicit relations) a=
nd
> at the same time maximising automation (framework) of the management
> of the relations.

  I'm not clear at all on what you mean by: minimum number of explicit
  relations. Why do relations bother you so much? Is this because of the
  previous statement about toMany relations being required to have an
  inverse?  This requirement has really nothing to do w/ inheritance, it
  just says that a toMany relationship from entity e1 to e2 must have an
  inverse. Now speaking of inheritance, the sub-entities *must* include
  the set of the inherited attr. & rels., this is because the model maps
  object to relational --however your (generated) classes will _inherit_
  the relations and attributes, and they wont re-declare them: the
  replication will only be in the model. Similarly, the business-logic
  attached to rel. toTree in class Node will be inherited in A, B and C.

> Have not yet tried to prototype such an example, but will plunge soon=
...
> Any "wisdom" comments very much appreciated.

I just hope I succeeded to make myself clear, and that I did not miss
some important points in your post...

        Cheers,

-- S=E9bastien.

Re: [Modeling-users] Limit

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

> Limit to a fixed maximum number? Don't think you can (for Sebastien to
> confirm) unless there is hidden support for specifying TOP N on SELEC=
Ts
> (which i think is not standard SQL?). And, how would you get the next=
 batch
> then?

  Sorry soif, Mario's right... there's currently no way to limit or bat=
ch
  the fetch. However EditingContext.objectsCountWithFetchSpecification()
  will tell you how many objects (in fact, the upper limit) you'll get =
if
  you send the same parameters to objectsWithFetchSpecification().

  More on this: if someone knows some standard SQL for doing this, I'm
  interested, it would for sure make the release-time for such a featur=
e,
  if requested, closer than it actually is.

> would be really nice to have a generic declarative way for this
> (essentially cursors, or paging, but as far the client app code is
> concerned, there should be no worries about maintaining state
> information).

Sure. Know what? It's on the TODO list :)

        Cheers,

-- S=E9bastien.

PS: I'll be off from now until tomorrow evening, but you can still expe=
ct
    v0.9 being released this week-end.

>=20
> > Hi all :)
> >
> >
> > I'm just wondering how can i limit the result fetched by
> > a qualifier. I think i forgot how this work :)
> >
> >

[Modeling-users] [Core & ZModeling] Release 0.8.6

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

        Hi all,

  This release is normally the last one of the 0.8 series. It is made of
  bug-fixes, the most important one addresses a possibility for to-many
  snapshots to be out-of-sync. wrt. to the database state. As usual the
  full changelog for that release is enclosed at the end of the message.

  The User's Guide has also been reviewed, corrected and enhanced --many
  thanks to Mario Ruggier for his time and effort on this, this work is
  all his.

  Additionally, I made a few changes on the w3-site
  http://modeling.sf.net ; I'm no web-designer but hopefully you'll find
  it clearer.


Important (I almost forgot, silly me): if you're using the framework in
--------- a long-standing process (being alive for more than 24 hours),
          I strongly suggest that you upgrade your copy and that you do
          NOT set MDL_PERMANENT_DB_CONNECTION (see changelog below) ; I
          have experienced strange behaviour with long-standing
          processes (w/ python2.1 & Zope 2.6, psycopg v1.0.14 and
          1.0.15, and PG server 7.2), such as committed changes being
          correctly issued by the psycopg adaptor but never committed
          within the postgresql server, hence causing the corresponding
          transaction to be *lost* (when this happens, you see a
          postgresql 'idle transaction in progress', never ending until
          the python process itself dies)

  While the exact reason for this problem is not completely clear at the
  moment, it was solved by the new behaviour (which closes the
  connection to the db as soon as no more adaptor channels are opened).

  Please also note that the environment variables have changed and are
  now prefixed w/ 'MDL_' to avoid any name clashes.

      Best regards,


-- S=E9bastien.



------------------------------------------------------------------------
0.8.6 (2002/02/21)
-----

  * doc/

      Committed changes on abstract.tex & UserGuide's CustomObject.tex,
      DefiningaModel.tex and ManipulatingGraphOfObjects.tex on behalf of
      Mario Ruggier who reviewed, corrected and enhanced the
      documentation. Thanks a lot!

      + HomePage/ re-organized (this part is used to generate the w3
        site http://modeling.sourceforge.net)

  * DatabaseContext:

    Fixed: adaptor channels are expected to be closed when any of the
           following operations terminates: fetch
           (ec.objectsWithFetchSpec), insert, update or delete
           (ec.saveChanges). The later (saveChanges()) did not close the
           underlying adaptorChannel.

       (see tests.test_AdaptorLayer.test_01_adaptorChannels_are_closed()
        and DatabaseContext._endTransaction())

  * Database Adaptors:

    + AdaptorChannel API: modified the contract for closeChannel(): an
        already closed adaptor channel should not fail when receiving
        the closeChannel() message --however in this situation
        adaptorChannelDidClose() should not be sent to the
        AdaptorContext.

    + AbstractDBAPI2AdaptorContext.adaptorChannelDidClose(): now closes
      the db-connection when closing the last opened
      AdaptorChannel. This behaviour can be changed by setting the
      environment variable MDL_PERMANENT_DB_CONNECTION.

    + fixed PGAdaptorContext.adaptorChannelDidClose(): do not try to
            rollback a db-connection which has been already closed.

  * DatabaseChannel.cancelFetch(): forgot to close the underlying
    adaptor channel. Fixed.

  * environment variables are now prefixed w/ 'MDL_':
      MDL_POSTGRESQL_SERVER_VERSION, MDL_ENABLE_DATABASE_LOGGING,
      MDL_PREFERRED_PYTHON_POSTGRESQL_ADAPTOR

  * DatabaseContext:

    - fixed arrayFaultForGlobalID() signature which did not follow the
      specification of interfaces.ObjectStoreInterface

    - fixed performChanges(): it was possible for a toMany snapshot
      stored in object Database (responsible for snapshots) to get
      out-of-sync with the database, when an object got no modification
      but in one (or more) of its toMany-relationships. After it
      occured, any other EditingContext was obtaining that out-of-sync
      toMany snapshot and when it was triggered, the framework did try
      to fetch, for the best, an object that still exists but shouldn't
      be related, for the worse an object that was removed from the
      database.  (see also: comments left in the source)

      (specifically tested in:
       test_EC_Global.test_16_toManySnapshotsUpdated)

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

Re: [Modeling-users] Limit

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

Limit to a fixed maximum number? Don't think you can (for Sebastien to 
confirm)
unless there is hidden support for specifying TOP N on SELECTs (which i 
think
is not standard SQL?). And, how would you get the next batch then?

You probably have to do a count, and if too many you modify the fetch 
qualifier
to be more restrictive. But, i guess it would be you who would have to 
program
such an algorithm for you app -- would be really nice to have a generic 
declarative
way for this (essentially cursors, or paging, but as far the client app 
code is
concerned, there should be no worries about  maintaining state 
information).

mario

> Hi all :)
>
>
> I'm just wondering how can i limit the result fetched by
> a qualifier. I think i forgot how this work :)
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Modeling-users mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modeling-users

Re: [Modeling-users] XML model suggestion

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

OK. The suggestion is essentially a cosmetic one, and probably
an even stronger argument against it would be that the changes
it will necessitate are not worth it. My aesthetic sense makes me
prefer less verbose XML... the argument that a pk is really an
attribute of an entity and not of an attribute seems reasonable--if
it would ever be possible that this fact may manifest itself in
some physical way, e.g. would it be ever possible to "share"
attributes between entities (such as inheritance) but that in
an entity a given attribute may be a pk but in another entity
the same entity is not.

In any case, this is low-priority.

Cheers, mario


On jeudi, f=E9v 20, 2003, at 22:57 Europe/Amsterdam, Sebastien Bigaret=20=

wrote:

>
>         Hi,
>
> Mario Ruggier <ma...@ru...> writes:
>> familiarizing myself with the framework, I suggest the following
>> modification to the XML to describe a model:
>>
>>   Instead of the XML elements:
>>
>>        <primaryKey ...
>>        <attributesUsedForLocking ...
>>
>> use XML attributes on the <attribute> XML element, i.e.
>>
>>        <attribute ... primaryKey=3D"1" ...
>>        <attribute ... usedForLocking=3D"1" ...
>>
>> This seems clearer, is less verbose,
>
> Well, the reason why it is like this entirely comes from Entity's API:
> these two elements really point out an entity's (not an attribute's)
> characteristics.
>
>   For attributesUsedForLocking: yes, I guess this could become an
>   attribute of the <attribute> tag (this tag is not used yet but will
>   identify the columns to be checked when optimistic-locking is
>   implemented). But to me this looks more like an entity's property=20
> than
>   an attribute's one.
>
> As far as the primaryKey is concerned, my opinion is much more
> mitigated. The primary key is a very important element in
> Entity-Relationship Modelling: not only because it uniquely identifies
> the row/object, but mainly because without it, no relationship/join =
can
> be defined --you may argue that foreign keys are not identified that
> way, true. Moreover and again, this designates a property of an =
entity,
> not an attribute's one.
>
>> and in any case keeps open your options to support changing your mind
>> about enforcing only one such attribute for each case -- should the
>> framework evolve that way.
>
> In that case, more than one <primaryKey> would be present in an =
Entity.
>
> I understand these are not strong reasons not to make the change, and
> that every of them can be argued: in this case, for example, why aint
> 'isClassProperty' or 'isRequired' element of entity?!
>
>   However I feel somehow reluctant in removing these tags from the
>   entity.  Maybe I'm too used to it, or maybe it partly comes from the
>   fact that I already feel a bit touchy about the xml-file, which=20
> should
>   be more human-readable than it actually is. I'll think about your
>   suggestions, though. And feel free to share if you have more=20
> arguments
>   for it, and to insist about that :)
>
> -- S=E9bastien.
>

[Modeling-users] Limit

[<so...@la...>]

Hi all :) 


I'm just wondering how can i limit the result fetched by 
a qualifier. I think i forgot how this work :) 

Re: Constraining primary keys (was: [Modeling-users] primary key + class property)

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

On vendredi, f=E9v 21, 2003, at 11:21 Europe/Amsterdam, Sebastien =
Bigaret=20
wrote:
>
> Mario:
>> Interesting discussion, especially as i was about to make what I
>> thought would be a nasty request (given the generous warnings! in the
>> guide ;-) for a particular situation, I would like to relate the pk =
of
>> a number of selected data tables, to guarantee that each key is =
unique
>> amongst those tables.
>> This will facilitate (simplify) having one or more other tables, such
>> as a user rights table, or a "hierarchy-imposing" table, to have
>> relations to each of the data tables -- the advantage would be that
>> the primary key in the "index" tables can be identical to the
>> corresponding row's pk, whatever data table it is in.
>
> Let me rephrase it to make sure I did understand:
>
> - you have some tables, say T1, T2 and T3, for which you want to have =
a
>   unique pk-generation scheme, i.e. where a pk value in T1 cannot be a
>   pk value in t2 and in t3

Exactly.

> - you want to have one or more tables/entities with relationships
>   pointing to t1, t2 and t3. Here I do not really understand your =
point
>   about << the primary key in the "index" tables [being] identical to=20=

> the
>   corresponding row's pk >> ; could you write a little example?

OK, this is where maybe I am not so clear myself as to how best
to go about it--i tend to think of these relations being always of type
dataTable-to-indexTable. Thus, indexTable rows are really not aware of
what they point to (or rather, who is pointing to them) -- except,=20
obviously, that
one would be able to navigate from an indexTable row to a dataTable row,
even without explicit outgoing relationships on the indexTable,=20
facilitated by
the fact that the primaryKey are identical. However, from the dataTable=20=

end,
each table provides an explicit relationship into any desired
indexTable, helping enforce that the management of a data row's
index entry "belongs" to the data row, i.e. the logic to add or delete
a data row will include the logic to add or delete (or modify)
all affected index entries.

Example:

NODE      an index table
id: 		int pk
name: 	str
type: 	enum : A | B | C  (defined via some rel to another TYPE table,=20=

thus
                    adding possibility to specify some meta-data for=20
each type,
		e.g; an icon)

TREE	index imposes a hierarchy on NODE rows
treeId:	int pk
parent	rel to Node.pk
child		rel to Node.pk

A
id: 		int pk
a1
a2
toNode	explicit relation to Node, and with A.id =3D Node.id

similarly for B and C

How would be best to model such a structure?

(This also raises the question whether the limitation mentioned in the=20=

manual
in section 2.3.2 is still valid... namely that "that toMany=20
relationships must have
inverse (toOne) relationships defined in the model".)


>> This can be done by either:
>> (a) the framework allowing pk definition responsability to
>> the application code, or
>> (b) building into the model capabilities a way to express
>> this, from which the framework will do everything correctly (very
>> nice)...
>
> I'm afraid (a) won't be possible in short-term
> About (b): there is already such a mechanism you can use for at least
> part of your requirements: inheritance! Even if T1, T2 and T3 have
> nothing in common, you can always make them sub-entities of a fake
> root-entity. This will ensure that the pk values assigned to rows T1,=20=

> T2 and
> T3 will never intersect (this is, in fact, exactly what make it=20
> possible
> to design a relationship from an entity to another one being part of =
an
> inheritance tree).

Ah, i did not realise that inheritance enforces that pk's are unique=20
across
all rows in the inheritance tree! In the above example, then, would it=20=

be
enough to make A, B and C inherit from NODE? What about implications
on TREE and TYPE? A, B and C are not related directly to these, but
when adding/deleting a row in A, this will cause a row to be added in=20
NODE,
as well as trigger the update to TREE to take this into account (with=20
the
addition of custom application logic, to know where in the Tree this=20
node
is attached).

I am looking for a way to implement the example construct above, while
staying as light as possible (minimum number of explicit relations) and
at the same time maximising automation (framework) of the management
of the relations.

Have not yet tried to prototype such an example, but will plunge soon...
Any "wisdom" comments very much appreciated.

>> Shall I submit this as a feature req in the tracker?
> After we make sure we do understand each other, certainly: that's the=20=

> best
> way to make sure that I won't forget !

It may then not be a feature request, but a modeling problem.
If a feature becomes apparent, let me know, and I will submit.

Cheers,

mario


> -- S=E9bastien.
>
>
>
>> On jeudi, f=E9v 20, 2003, at 23:34 Europe/Amsterdam, Sebastien =
Bigaret
>> wrote:
>>> This also rings a bell about one future feature, where you would be
>>> able
>>> to set the primary key according to your own scheme --in this case,
>>> having None or 0 (or even '') would mean ''use automatic PK
>>> generation'', while any other value will be used as-is for the PK
>>> value,
>>> hence bypassing the automatic generation.  I'll think of it and keep
>>> you
>>> informed of the evolution.
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
>> The most comprehensive and flexible code editor you can use.
>> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day =
Trial.
>> www.slickedit.com/sourceforge
>> _______________________________________________
>> Modeling-users mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modeling-users
>

Re: Constraining primary keys (was: [Modeling-users] primary key + class property)

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

Mario:
> Interesting discussion, especially as i was about to make what I
> thought would be a nasty request (given the generous warnings! in the
> guide ;-) for a particular situation, I would like to relate the pk of
> a number of selected data tables, to guarantee that each key is unique
> amongst those tables.
> This will facilitate (simplify) having one or more other tables, such
> as a user rights table, or a "hierarchy-imposing" table, to have
> relations to each of the data tables -- the advantage would be that
> the primary key in the "index" tables can be identical to the
> corresponding row's pk, whatever data table it is in.

Let me rephrase it to make sure I did understand:

- you have some tables, say T1, T2 and T3, for which you want to have a
  unique pk-generation scheme, i.e. where a pk value in T1 cannot be a
  pk value in t2 and in t3

- you want to have one or more tables/entities with relationships
  pointing to t1, t2 and t3. Here I do not really understand your point
  about << the primary key in the "index" tables [being] identical to t=
he
  corresponding row's pk >> ; could you write a little example?

> This can be done by either:
> (a) the framework allowing pk definition responsability to
> the application code, or
> (b) building into the model capabilities a way to express
> this, from which the framework will do everything correctly (very=20
> nice)...

I'm afraid (a) won't be possible in short-term
About (b): there is already such a mechanism you can use for at least
part of your requirements: inheritance! Even if T1, T2 and T3 have
nothing in common, you can always make them sub-entities of a fake
root-entity. This will ensure that the pk values assigned to rows T1, T=
2 and
T3 will never intersect (this is, in fact, exactly what make it possible
to design a relationship from an entity to another one being part of an
inheritance tree).

> Shall I submit this as a feature req in the tracker?
After we make sure we do understand each other, certainly: that's the b=
est
way to make sure that I won't forget !


-- S=E9bastien.

=20=20=20=20=20=20=20=20

> On jeudi, f=E9v 20, 2003, at 23:34 Europe/Amsterdam, Sebastien Bigare=
t=20
> wrote:
> > This also rings a bell about one future feature, where you would be=
=20
> > able
> > to set the primary key according to your own scheme --in this case,
> > having None or 0 (or even '') would mean ''use automatic PK
> > generation'', while any other value will be used as-is for the PK=20
> > value,
> > hence bypassing the automatic generation.  I'll think of it and kee=
p=20
> > you
> > informed of the evolution.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Modeling-users mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modeling-users

Constraining primary keys (was: [Modeling-users] primary key + class property)

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

Interesting discussion, especially as i was about to make what I thought
would be a nasty request (given the generous warnings! in the guide ;-)
for a particular situation, I would like to relate the pk of a number=20
of selected
data tables, to guarantee that each key is unique amongst those tables.
This will facilitate (simplify) having one or more other tables, such=20
as a user rights
table, or a "hierarchy-imposing" table, to have relations to each of the
data tables -- the advantage would be that the primary key in the=20
"index" tables
can be identical to the corresponding row's pk, whatever data table it=20=

is in.

This can be done by either:
(a) the framework allowing pk definition responsability to
the application code, or
(b) building into the model capabilities a way to express
this, from which the framework will do everything correctly (very=20
nice)...

Would does everyone think?
Is, at least, (a) possible in short-term?
Shall I submit this as a feature req in the tracker?

Best regards,

Mario Ruggier


On jeudi, f=E9v 20, 2003, at 23:34 Europe/Amsterdam, Sebastien Bigaret=20=

wrote:
> This also rings a bell about one future feature, where you would be=20
> able
> to set the primary key according to your own scheme --in this case,
> having None or 0 (or even '') would mean ''use automatic PK
> generation'', while any other value will be used as-is for the PK=20
> value,
> hence bypassing the automatic generation.  I'll think of it and keep=20=

> you
> informed of the evolution.

Re: [Modeling-users] primary key + class property

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 20 February 2003 05:34 pm, Sebastien Bigaret wrote:
> Definitely!  Thanks a lot for reporting this.

No problems.

While I'm at it, there is a typo in mdl_generate_python_code.py

$ mdl_generate_python_code.py 2>&1 | grep stpped
  exists, the build process is stpped       <---        stpped

Regards, 

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+VVAYrhy5Fqn/MRARAiK3AJ0ZTfXj/uzdn00KhwyGOJ3G34Wi0gCgk2VZ
Ui8gtsyyzYfKUu6UrxhJ+XU=
=lpil
-----END PGP SIGNATURE-----

Re: [Modeling-users] primary key + class property

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

Yannick Gingras <yan...@sa...> writes:
[about PK being class properties NOT being automatically generated]
> I had a default value set to 'None' for the primary key of an entity.
> It worked perfectly as long as the primary key was not a class
> property.  When I turned it (the primary key) to a class property, I
> was not able to create an object anymore.  When saving the changes,
> the editing context was complaining about a required field not
> initialized.  I changed the default value to 0 and it worked.

Ok, that makes sense: the validation process was preventing the
framework to save the changes, hence the primary key had no chance to
get its value.

This also rings a bell about one future feature, where you would be able
to set the primary key according to your own scheme --in this case,
having None or 0 (or even '') would mean ''use automatic PK
generation'', while any other value will be used as-is for the PK value,
hence bypassing the automatic generation.  I'll think of it and keep you
informed of the evolution.

> Should be in the FAQ !
> ; )

Definitely!  Thanks a lot for reporting this.

-- S=E9bastien.

Re: [Modeling-users] primary key + class property

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 20 February 2003 04:56 pm, you wrote:
> > > How can I have *automatic* primary keys that I can see ?
> >
> > By setting default value to 0 + isRequired to 1.
>
> Could you please be more specific? Do you say that automatic generation
> of primary key does not work if you define it as a class property???
> More on this: the framework does not support setting the primary key of
> an object by hand --that's why I really want more details on what
> happened to you here.
>
>   If this is the case, this is a bug I really want to trace: this should
>   NOT happen, and I cant even see now how automatic pk generation could
>   be defeated when the primary key is a class property (it is nnot even
>   checked when insertedObjects of an EditingContext are processed).
>
> However you are right: the default value should be 0, and isRequired
> must always be set to 1 for a PK (being a class property or not).

I had a default value set to 'None' for the primary key of an entity.
It worked perfectly as long as the primary key was not a class
property.  When I turned it (the primary key) to a class property, I
was not able to create an object anymore.  When saving the changes,
the editing context was complaining about a required field not
initialized.  I changed the default value to 0 and it worked.

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+VUPprhy5Fqn/MRARAoHUAKCQvgh2zKEYWa87aBd5CPrKxMgLFQCfQ2Li
Mk1ImygzRKW2Hq3RcCFVo48=
=L4/r
-----END PGP SIGNATURE-----

Re: [Modeling-users] XML model suggestion

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

        Hi,

Mario Ruggier <ma...@ru...> writes:
> familiarizing myself with the framework, I suggest the following
> modification to the XML to describe a model:
>=20
>   Instead of the XML elements:
>=20
>        <primaryKey ...
>        <attributesUsedForLocking ...
>=20
> use XML attributes on the <attribute> XML element, i.e.
>=20
>        <attribute ... primaryKey=3D"1" ...
>        <attribute ... usedForLocking=3D"1" ...
>=20
> This seems clearer, is less verbose,=20

Well, the reason why it is like this entirely comes from Entity's API:
these two elements really point out an entity's (not an attribute's)
characteristics.

  For attributesUsedForLocking: yes, I guess this could become an
  attribute of the <attribute> tag (this tag is not used yet but will
  identify the columns to be checked when optimistic-locking is
  implemented). But to me this looks more like an entity's property than
  an attribute's one.

As far as the primaryKey is concerned, my opinion is much more
mitigated. The primary key is a very important element in
Entity-Relationship Modelling: not only because it uniquely identifies
the row/object, but mainly because without it, no relationship/join can
be defined --you may argue that foreign keys are not identified that
way, true. Moreover and again, this designates a property of an entity,
not an attribute's one.

> and in any case keeps open your options to support changing your mind
> about enforcing only one such attribute for each case -- should the
> framework evolve that way.

In that case, more than one <primaryKey> would be present in an Entity.

I understand these are not strong reasons not to make the change, and
that every of them can be argued: in this case, for example, why aint
'isClassProperty' or 'isRequired' element of entity?!

  However I feel somehow reluctant in removing these tags from the
  entity.  Maybe I'm too used to it, or maybe it partly comes from the
  fact that I already feel a bit touchy about the xml-file, which should
  be more human-readable than it actually is. I'll think about your
  suggestions, though. And feel free to share if you have more arguments
  for it, and to insist about that :)

-- S=E9bastien.

Re: [Modeling-users] primary key + class property

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

Yannick Gingras <yan...@sa...> writes:
> On Thursday 20 February 2003 02:49 pm, Yannick Gingras wrote:
> > I saw in the FAQ that I could see my primary keys by setting them as
> > class properties.  If I try this, I need to set them by hand.
> >
> > How can I have *automatic* primary keys that I can see ?
>=20
> By setting default value to 0 + isRequired to 1.

Could you please be more specific? Do you say that automatic generation
of primary key does not work if you define it as a class property???
More on this: the framework does not support setting the primary key of
an object by hand --that's why I really want more details on what
happened to you here.

  If this is the case, this is a bug I really want to trace: this should
  NOT happen, and I cant even see now how automatic pk generation could
  be defeated when the primary key is a class property (it is nnot even
  checked when insertedObjects of an EditingContext are processed).

However you are right: the default value should be 0, and isRequired
must always be set to 1 for a PK (being a class property or not).


-- S=E9bastien.

Re: [Modeling-users] primary key + class property

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 20 February 2003 02:49 pm, Yannick Gingras wrote:
> I saw in the FAQ that I could see my primary keys by setting them as
> class properties.  If I try this, I need to set them by hand.
>
> How can I have *automatic* primary keys that I can see ?

By setting default value to 0 + isRequired to 1.

Should be in the FAQ !

 ; )

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+VTMPrhy5Fqn/MRARAs55AJ9yPJmvAAm09aekGUOOB6elyL9rTwCghRFr
+UypJiYLO6E1rJLYOk/jqIA=
=2x4z
-----END PGP SIGNATURE-----