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

Re: [Modeling-users] API cleanup proposal

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

>         Hi all,
>
>   Here is a proposal to change some of the most commonly used methods;
> the general idea is to improve developers' experience with the=20
> framework
> by providing better, cleaner, shorter names for existing=20
> functionalities.

I would also add "by indicating clearly the small subset of methods=20
intended
for use by client code, and the stability level".

>  [Note on "most commonly used methods": I do not plan to change every
>   method's name when it's too long: they are mostly for the =
framework's
>   use, or at best for advanced usage]


> EditingContext (remember: an EC can be thought as a transaction)
> --------------
>
>   - insert() instead of insertObject()
>
>   - delete() instead of deleteObject()

OK. What about commit() for saveChanges()?

>   - fetching: remove the need to import FetchSpecification and
>     Qualifier, and propose an alternate for
>     objectsWithFetchSpecification()
>
>        def fetch(self, entityName,
>                  qualifier=3DNone, # either a Qualifier instance or a=20=

> string
>                  orderBy=3DNone,   # either a SortOrdering or a string
>                  isDeep=3D0,       # should subentities be fetched as=20=

> well?
>                  refresh=3D0,      # unsupported yet
>                  lock=3D0,         # unsupported yet
>                  limit=3DNone,     # \
>                  page=3DNone,      #  > slice parameters, not in core =
yet
>                  offset=3DNone,    # /  (page/offset: mutually =
exclusive)
>                 )
>
>     Typical usage:
>
>       ec.fetch('Writer', 'lastName ilike "hu?o"')
>       ec.fetch('Writer', 'age>=3D80"')
>       ec.fetch('Writer', 'author.pygmalion.lastName=20
> caseInsensitiveLike "r*"')
>       ec.fetch('Writer', orderBy=3D'firstName asc, lastName desc',=20
> isDeep=3D1)
>       ec.fetch('Books', orderBy=3D'title', limit=3D10, page=3D1)

Yes, this is much easier than using FetchSpecification and=20
QualifierFormats...

I feel that some things (even if no one has requested them yet ;) are=20
missing...
for example, should one ever need to take advantage of sql "group by"=20
and "having".
Access to these sql clauses may be added later, without breaking this=20
API,
which is OK. Also, such manips may be done in the middle code, but
that would be very inefficient.

Another issue is that even with all the keyword options offered, one=20
still
has to "dip into" small pieces of raw sql very quickly, as shown by your
examples. This may be an acceptable compromise, but then client code
should be allowed to pass any SQL it wants...

Another detail is that the object loads all (direct) properties, every=20=

time --
there may be no workaround for this, given the way the framework is=20
built.
The real problem with this is that to request the result of an sql=20
function,
of which count() is an example, additional api functionality is needed.
But what happens if I want other functions, such as SUM or MAX or=20
AVERAGE
over a few columns? Each of these functions may take complex parameters.
Again, the functionality may be replicated in the middle code, but this=20=

would
not only be a waste of development time, but also be very inefficient.

I propose either a generalization of "select" (which may be too=20
complicated
in its implications), or an addition of a func keyword option, e.g.

func=3D'count'
func=3D('funcName', param1, param2, ...)
func=3D( ('funcName', param1, param2, ...), ('funcname2') )

func=3D('sum','age')

The question is then how is this information returned?
I suggest as a tuple...

Which reminds me that it would be nice to have a convenience
"resultset" option, that when true returns results as a db resulset.
This implies that one should not mix, in the same non-resultset fetch,
requests for real objects and for additional "virtual" properties,
such as counts, sums, etc. (Or stated differently, the presence
of func will cause data to be returned as a tuple.)


>   - replace objectsCountWithFetchSpecification() with fetchCount() ?
>       [same API as fetch()]

I propose use fetch() as descibed above:

ec.fetch('Writer', qualifier=3D'age>=3D80"', func=3D'count')
=3D> (3)

but also:

ec.fetch('Writer', qualifier=3D'age>=3D80"',=20
func=3D(('count'),('max','age'),('average','age')) )
=3D> (3,91,85)

[ or else we can stick to raw sql:
ec.fetch('Writer', qualifier=3D'age>=3D80"', func=3D'count(*), max(age),=20=

average(age)' )
which may be simpler for everyone... in this case might as well change=20=

'func' to 'select',
which will always assume a 'resulset' response ]


>   - replace (set)propagatesInsertionForRelatedObjects() with
>     autoInsertion() and setAutoInsertion()

I prefer setAutoInsertion()


>
> CustomObject
> ------------
>
>   I don't see any methods to change here. Maybe we could add=20
> globalID()?
>   However, the name itself 'CustomObject' could be changed if you have
>   some ideas (I admit it is not very representative of what it does,
>   i.e. defining generic methods for an object to be bound w/ the
>   framework)

CustomObject will inherit the changes to the KeyValueCoding API,
so it should be OK.

CustomObject as name is not so bad. Other names that come to
mind are MappedObject, ManagedObject, MorfedObject ;)
PersistedObjected


> Validation
> ----------
>
>   Do we need to change anything there? validateValueForKey() is the
>   longest one, however I think this is not widely used, is it?

I suggest validateProperty() instead of validateValueForKey().


>
> KeyValueCoding
> --------------
>
>   As Mario repeatedly pointed it out some time ago, this module needs=20=

> to
>   be cleaned.
>
>   Core methods:
>
>
>           |   [public access]         |    [private access]
>    =20
> ------+---------------------------+----------------------------------
>     [get] |valueForKey()              | storedValueForKey()
>           |valueForKeyPath()          |
>    =20
> ------+---------------------------+----------------------------------
>     [set] |takeValueForKey()          | takeStoredValueForKey()
>           |takeValueForKeyPath()      |
>    =20
> ------+---------------------------+----------------------------------
>     [dict]|takeValuesFromDictionary() |=20
> takeStoredValuesFromDictionary()
>
>   Quick reminder: KVC is intensively used by the framework to get & =
set
>                   an object's values without knowing where it is
>                   actually stored (for example, attribute 'name' can =
be
>                   stored in name, _name, and/or can be accessed/set =
via
>                   getters/setters name/getName()/setName())
>
>   The framework *always* uses the so-called "private" access
>   methods. The reason is that e.g. a public setter can have some
>   side-effect that should be triggered from a user's point of view (at
>   creation or modification time), but shouldn't be triggered when
>   object's data are fetched from the db (this is not very common,
>   though, hence I think we need a simplified and more efficient KVC =
for
>   the common cases --off-topic here).
>
>   This is my proposal:
>
>   * getProp(name, path):
>
>        getProp(key)          replaces valueForKey(key)
>        getProp(path=3DkeyPath) replaces valueForKeyPath(keyPath)

I like the use of path instead of another method. However does
this imply an extra check per call? Also, when specified path must
include name... is this better than path must never include name?

>   * setProp(name, path):
>
>        setProp(key)          replaces takeValueForKey(key)
>        setProp(path=3DkeyPath) replaces takeValueForKeyPath(keyPath)
>
>   * same for getStoredProp() and setStoredProp() which replace
>     (take)storedValueForKey
>
>  Notes: - parameters name & path are obviously mutually exclusive,
>         - get/setStoredProp shouldn't be needed from a developer's=20
> point
>           of view.
>
>   * updateProps()       replaces takeValuesFromDictionary()
>     updateStoredProps() replaces takeValuesFromStoredDictionary()

OK for this, but I would in these case prefer to use the full word=20
(respecting
the naming convention so far...), i.e.:

co.getProperty()
co.setProperty()
co.getStoredProperty()
co.setStoredProperty()
co.updateProperties()
co.updateStoredProperties()


>   Along with that, we also need an other module/class name for
>   KeyValueCoding.
>
>   Mario proposed PropValueAccess. Any ideas?
>                                             GenericAccess?=20
> PropHandling?
>

I would be in favour of combining with RelationshipManipulation...

> RelationshipManipulation
> ------------------------
>
>   Any thoughts about how addObjectToBothSidesOfRelationshipWithKey()=20=

> and
>   removeObjectFromBothSidesOfRelationshipWithKey() can be renamed?

How about addViaRelation() and removeViaRelation()

> =3D> An other solution could be: gather KVC and =
RelationshipManipulation
>    in a single module, since they both address the same thing: generic
>    manipulation of an object, given its definition in the model. What=20=

> do
>    you think?

Yes. How about MappedObject PR?
For Properties and Relations of course ;)
Module name could be "mopr" or simply "opr".


> BTW this is not a definitive list, just the things I know that need to
> be changed. If you feel like changing other names please tell.
>
>
>   Your feedback is greatly appreciated!-)
>
>
> -- S=E9bastien.

mario

Re: [Modeling-users] API cleanup proposal

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

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

On Monday 02 June 2003 14:10, Sebastien Bigaret wrote:
>  [Note on "most commonly used methods": I do not plan to change every
>   method's name when it's too long: they are mostly for the framework's
>   use, or at best for advanced usage]

Please make aliases for backward compatibility.

  : )

The proposal sounds really fair to me !

- -- 
Yannick Gingras
Coder for OBB : Obscenely Base Bottlegrass
http://OpenBeatBox.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+3Avarhy5Fqn/MRARAqX8AJsHZcGE2QW+Uf+N8su6mCkkCJeCSACgjhEe
Ad0Tl6Gqiw9xV3J4lUdjDyA=
=fNcy
-----END PGP SIGNATURE-----

[Modeling-users] API cleanup proposal

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

        Hi all,

  Here is a proposal to change some of the most commonly used methods;
the general idea is to improve developers' experience with the framework
by providing better, cleaner, shorter names for existing functionalities.

 [Note on "most commonly used methods": I do not plan to change every
  method's name when it's too long: they are mostly for the framework's
  use, or at best for advanced usage]


EditingContext (remember: an EC can be thought as a transaction)
--------------

  - insert() instead of insertObject()

  - delete() instead of deleteObject()

  - fetching: remove the need to import FetchSpecification and
    Qualifier, and propose an alternate for
    objectsWithFetchSpecification()

       def fetch(self, entityName,
                 qualifier=3DNone, # either a Qualifier instance or a string
                 orderBy=3DNone,   # either a SortOrdering or a string
                 isDeep=3D0,       # should subentities be fetched as well?
                 refresh=3D0,      # unsupported yet
                 lock=3D0,         # unsupported yet
                 limit=3DNone,     # \
                 page=3DNone,      #  > slice parameters, not in core yet
                 offset=3DNone,    # /  (page/offset: mutually exclusive)
                )
=20=20=20=20
    Typical usage:

      ec.fetch('Writer', 'lastName ilike "hu?o"')
      ec.fetch('Writer', 'age>=3D80"')
      ec.fetch('Writer', 'author.pygmalion.lastName caseInsensitiveLike "r*=
"')
      ec.fetch('Writer', orderBy=3D'firstName asc, lastName desc', isDeep=
=3D1)
      ec.fetch('Books', orderBy=3D'title', limit=3D10, page=3D1)

  - replace objectsCountWithFetchSpecification() with fetchCount() ?
      [same API as fetch()]

  - replace (set)propagatesInsertionForRelatedObjects() with
    autoInsertion() and setAutoInsertion()


CustomObject
------------

  I don't see any methods to change here. Maybe we could add globalID()?
  However, the name itself 'CustomObject' could be changed if you have
  some ideas (I admit it is not very representative of what it does,
  i.e. defining generic methods for an object to be bound w/ the
  framework)


Validation
----------

  Do we need to change anything there? validateValueForKey() is the
  longest one, however I think this is not widely used, is it?


KeyValueCoding
--------------

  As Mario repeatedly pointed it out some time ago, this module needs to
  be cleaned.

  Core methods:


          |   [public access]         |    [private access]
    ------+---------------------------+----------------------------------
    [get] |valueForKey()              | storedValueForKey()
          |valueForKeyPath()          |
    ------+---------------------------+----------------------------------
    [set] |takeValueForKey()          | takeStoredValueForKey()
          |takeValueForKeyPath()      |
    ------+---------------------------+----------------------------------
    [dict]|takeValuesFromDictionary() | takeStoredValuesFromDictionary()
=20=20
  Quick reminder: KVC is intensively used by the framework to get & set
                  an object's values without knowing where it is
                  actually stored (for example, attribute 'name' can be
                  stored in name, _name, and/or can be accessed/set via
                  getters/setters name/getName()/setName())

  The framework *always* uses the so-called "private" access
  methods. The reason is that e.g. a public setter can have some
  side-effect that should be triggered from a user's point of view (at
  creation or modification time), but shouldn't be triggered when
  object's data are fetched from the db (this is not very common,
  though, hence I think we need a simplified and more efficient KVC for
  the common cases --off-topic here).

  This is my proposal:

  * getProp(name, path):

       getProp(key)          replaces valueForKey(key)
       getProp(path=3DkeyPath) replaces valueForKeyPath(keyPath)

  * setProp(name, path):

       setProp(key)          replaces takeValueForKey(key)
       setProp(path=3DkeyPath) replaces takeValueForKeyPath(keyPath)

  * same for getStoredProp() and setStoredProp() which replace
    (take)storedValueForKey
=20=20
 Notes: - parameters name & path are obviously mutually exclusive,
        - get/setStoredProp shouldn't be needed from a developer's point
          of view.

  * updateProps()       replaces takeValuesFromDictionary()
    updateStoredProps() replaces takeValuesFromStoredDictionary()


  Along with that, we also need an other module/class name for
  KeyValueCoding.

  Mario proposed PropValueAccess. Any ideas?
                                            GenericAccess? PropHandling?


RelationshipManipulation
------------------------

  Any thoughts about how addObjectToBothSidesOfRelationshipWithKey() and
  removeObjectFromBothSidesOfRelationshipWithKey() can be renamed?=20



=3D> An other solution could be: gather KVC and RelationshipManipulation
   in a single module, since they both address the same thing: generic
   manipulation of an object, given its definition in the model. What do
   you think?


BTW this is not a definitive list, just the things I know that need to
be changed. If you feel like changing other names please tell.


  Your feedback is greatly appreciated!-)


-- S=E9bastien.

Re: [Modeling-users] Request for specific adaptors?

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

> I have recently felt that an adaptor to a non-relational db server would
> be very nice -- useful for simple applications (and installations of)
> and/or
> quick prototyping, but will allow that the same application be easily
> "scaled-up"
> to a relational server (with no changes to the data model).
> This does not equate to simple object persistence (e.g. any of several
> such schemes available, from pickle to zodb, etc.). It is also not about
> performance ;-!. It is about giving a very high-level separation between
> the application objects, and the back-end, that will also allow
> switching
> between SQL and non-SQL storage. I am in particular thinking of
> something like bsddb, with string values (rows) that are simply
> repr(dict).
> Then searching and filtering can still be achieved without modifying
> any client code (albeit very inefficiently!). The advantage is that
> small applications that do not do so much searching and filtering
> do not suffer very much, and they can be installed a lot simpler
> (requiring only to make sure to have write access to some directory,
> as opposed to setting up an sql server). But, the power of the model
> is still at hand, on which the application can build...
>
> mario


This is a good idea, since I usually don't use modeling for small stuff
as i need to use a big SQL server w/. PySQLITE is really a great stuff
i think my next dev about modeling will use this.

Perhaps we should look at gadfly ? (or ZODB + SQL )

Re: [Modeling-users] Request for specific adaptors?

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

I have recently felt that an adaptor to a non-relational db server would
be very nice -- useful for simple applications (and installations of)=20
and/or
quick prototyping, but will allow that the same application be easily=20
"scaled-up"
to a relational server (with no changes to the data model).
This does not equate to simple object persistence (e.g. any of several
such schemes available, from pickle to zodb, etc.). It is also not about
performance ;-!. It is about giving a very high-level separation between
the application objects, and the back-end, that will also allow=20
switching
between SQL and non-SQL storage. I am in particular thinking of
something like bsddb, with string values (rows) that are simply=20
repr(dict).
Then searching and filtering can still be achieved without modifying
any client code (albeit very inefficiently!). The advantage is that
small applications that do not do so much searching and filtering
do not suffer very much, and they can be installed a lot simpler
(requiring only to make sure to have write access to some directory,
as opposed to setting up an sql server). But, the power of the model
is still at hand, on which the application can build...

mario


>   I have the feeling that a request for a specific adaptor was once=20
> made
>   here, but I cannot find it again in the archives. Maybe Oracle, or
>   Firebird?
>
> BTW if you have a oracle server at hand you can experiment with, and =
if
> you have some time testing an adaptor for oracle we could work =
together
> to make this happen; I cannot make this on my own: downloading 1.5Gb
> oracle for linux is far beyond my patience and bandwidth :/
>
> -- S=E9bastien.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Modeling-users mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modeling-users

Re: [Modeling-users] Stability of Modeling

[Edmund L. <el...@in...>]

ludovic Bellier wrote:

> And apply these advises :
> http://eeshop.unl.edu/rsi.html

Thanks for the link!

...Edmund.

Re: [Modeling-users] Stability of Modeling

[Edmund L. <el...@in...>]

Yannick Gingras wrote:

> You need auto-completion:
>  M-/ in emacs
>  C-p in vi
>  C-SPACE in a few others

Thanks--didn't think about this. I do use a Kinesis keyboard 
(http://www.kinesis-ergo.com/contoured.htm), and this has been the 
biggest help so far. But it is expensive!

...Edmund.

[Modeling-users] Request for specific adaptors?

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

  I have the feeling that a request for a specific adaptor was once made
  here, but I cannot find it again in the archives. Maybe Oracle, or
  Firebird?

BTW if you have a oracle server at hand you can experiment with, and if
you have some time testing an adaptor for oracle we could work together
to make this happen; I cannot make this on my own: downloading 1.5Gb
oracle for linux is far beyond my patience and bandwidth :/

-- S=E9bastien.

[Modeling-users] User's Guide (pdf): printing issues solved

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

        Hi,

  I forgot to mention it when releasing 0.9-pre-8: there were some
printing issues with acrobat reader v5+, possibly also with some v0.4+
on windows platforms.

These issues were due to hyperlinks in the pdf. Removing them apparently
solved the problem --the pdf available online should be ok now.

  Many thanks to Ernesto Revilla for reporting the problem and
  for finding the relevant solution.

-- S=E9bastien.

Re: [Modeling-users] MySQL TEXT

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

so...@la... wrote:
> I do, TEXT works great on mysql using this patch.=20

Fine :) However I'm a bit distracted here: support for TEXT was added for
mysql in 0.9pre4. I'm currently updating the documentation and will also
update the postgresql adaptor so that it also accepts it.

  Note: I'm not adding it to the core but specifically in adaptors since TE=
XT
        is not in ANSI SQL (AFAIK).
  [cf. http://www.mysql.com/doc/en/Extensions_to_ANSI.html and
       http://www.commandprompt.com/ppbook/index.lxp?lxpwrap=3Dx2632%2ehtm]

  It will be in next release, and soon on cvs.

-- S=E9bastien.




> On Sat, May 31, 2003 at 02:01:32PM +0200, Sebastien Bigaret wrote:
> >=20
> > Three months ago Yannick, then Soaf requested support for TEXT
> > sql-datatypes in mysql. A patch was posted for mysql but I got no
> > report.
> >=20
> > I think this should be added to the main trunk (for both mysql and
> > postgresql). Are some of you using this on a regular basis and can conf=
irm
> > that it's ok?
>=20=20
>=20
> I do, TEXT works great on mysql using this patch.=20

Re: [Modeling-users] MySQL TEXT

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

On Sat, May 31, 2003 at 02:01:32PM +0200, Sebastien Bigaret wrote:
> 
> Three months ago Yannick, then Soaf requested support for TEXT
> sql-datatypes in mysql. A patch was posted for mysql but I got no
> report.
> 
> I think this should be added to the main trunk (for both mysql and
> postgresql). Are some of you using this on a regular basis and can confirm
> that it's ok?
 

I do, TEXT works great on mysql using this patch. 





 

Re: [Modeling-users] MySQL TEXT

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

Three months ago Yannick, then Soaf requested support for TEXT
sql-datatypes in mysql. A patch was posted for mysql but I got no
report.

I think this should be added to the main trunk (for both mysql and
postgresql). Are some of you using this on a regular basis and can confirm
that it's ok?


-- S=E9bastien.


Sebastien Bigaret <sbi...@us...> wrote:
>         Hi,
>=20
> Yannick Gingras <yan...@sa...> wrote:
> > the user guide section 2.2.4 talk about CHAR and VARCHAR external type
> > support but there is no mention about the support for TEXT.  I have
> > really strange errors when using TEXT.
> >=20
> >   File "<stdin>", line 92, in insertElement
> >   File "/usr/lib/python2.2/site-packages/Modeling/EditingContext.py", l=
ine=20
> > 678, in saveChanges
> >     self.parentObjectStore().saveChangesInEditingContext(self)
> >   File "/usr/lib/python2.2/site-packages/Modeling/ObjectStoreCoordinato=
r.py",=20
> > line 559, in saveChangesInEditingContext
> >     raise RuntimeError, _error
> > RuntimeError: performChanges() failed on=20
> > <Modeling.DatabaseContext.DatabaseContext instance at 0x88dd2ec>:=20
> > exceptions.ValueError:Unknown value type: None for externalType: text=20
> > (attribute: JOBI18N.description)
> >=20
> > Is it possible I am positively certain that my default value is not
> > None and that I did put a value in JOBI18N.description before insert.
> >=20
> > Anyone have a clue about the cause ?
>=20
> Yes, this is because TEXT is an unknown sql type for the MySQLAdaptor.
> Didn't the validation of the model indicate it ?-)
>=20
> (I agree the message is not very informative, I added bug #699046)
>=20
>   It is raised by SQLExpression.formatValueForAttribute(), which got an
>   'None' type from valueTypeForExternalType().
>=20
> If TEXT is a valid mysql format mapped to a python string, then modify
> MySQLSQLExpression.valueTypeForExternalTypeMapping() in
> DatabaseAdaptors.MySQLAdaptorLayer:
>=20
> diff -c -r1.2 MySQLSQLExpression.py
> *** MySQLSQLExpression.py    1 Feb 2003 11:59:13 -0000        1.2
> --- MySQLSQLExpression.py    6 Mar 2003 22:18:13 -0000
> ***************
> *** 77,81 ****
>       """
>       values=3DSQLExpression.valueTypeForExternalTypeMapping.im_func(self)
>       del values['timestamp']
> !     values.update({ 'datetime': DateType })
>       return values
> --- 77,82 ----
>       """
>       values=3DSQLExpression.valueTypeForExternalTypeMapping.im_func(self)
>       del values['timestamp']
> !     values.update({ 'datetime': DateType,
> !                     'text': CharacterType })
>       return values
>=20
>=20
> (SQL types should be lower-cased)
>=20
>=20=20=20
>   This should work ; please report and I'll apply the patch when you
>   confirm that this is ok.
>=20
>         Regards,
>=20
>=20
> -- S=E9bastien.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugg=
er=20
> for complex code. Debugging C/C++ programs can leave you feeling lost and=
=20
> disoriented. TotalView can help you find your way. Available on major UNI=
X=20
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Modeling-users mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modeling-users

Re: [Modeling-users] Stability of Modeling

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

Edmund Lian <el...@in...> wrote:
> BTW, I know you're a bit "touchy" about the name, but it is an important
> issue. When I was trying to find more info about Modeling, searching on t=
he
> name was useless since it is such a widely used verb!

Alas, the problem is known and the name should be changed. My fault here
--some people here keep picking on me on a regular basis. I'll gather
the name proposals in a forthcoming mail and we'll try to make it happen
for 0.9 (that's one of the few remaining prerequisites to leave the
long-standing pre-0.9 serie).

> >> Does it scale well, etc.
> >   Could you be more specific about which kind of informations you'd
> >   like to get?
>=20
> I was after the kinds of numbers that you provided, thank you. I'll
> experiment with it soon to get a better feel for it.

Fine. I guess these figures should be put somewhere on the website.

> One thing that I'm concerned about is the use of very long method and
> parameter names, like:
>=20
> qualifier=3DqualifierWithQualifierFormat('lastName caseInsensitiveLike "h=
u?o"')
>=20
> My wrists started to hurt as soon as I saw this (I have RSI)!  :-)

Ouch! This is another known issue that should be addressed for 0.9 as
well. As Yannick said, auto-completion is your friend, however this is
not a definitive answer. I'll post soon a API-renaming proposal,
dedicated to the most useful methods --and fetching should be made
simpler.
  It should have been addressed for long --be sure it's not
unwillingness, rather a matter of time. As usual...

  As far as caseInsensitiveLike is concerned: I once made 'ilike' an
  alternate for 'caseInsensitiveLike', but it seems to have
  disappeared. Back again on cvs, and attached is the corresponding
  patch. This will be in next release.

-- S=E9bastien.

----------8<---------------8<---------------8<---------------8<---------
Index: Modeling/Qualifier.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/Qualifier.py,v
retrieving revision 1.5
diff -u -r1.5 Qualifier.py
--- Modeling/Qualifier.py       27 Jan 2003 22:41:59 -0000      1.5
+++ Modeling/Qualifier.py       31 May 2003 08:39:40 -0000
@@ -78,7 +78,7 @@
=20
 # Module
 def allQualifierOperators():
-  return ('=3D=3D', '!=3D', '<', '<=3D', '>', '>=3D', 'like', 'caseInsensi=
tiveLike')
+  return ('=3D=3D', '!=3D', '<', '<=3D', '>', '>=3D', 'like', 'caseInsensi=
tiveLike', 'ili
ke')
=20
 def filteredArrayWithQualifier(objects, qualifier):
   result=3D[]
@@ -96,7 +96,7 @@
   if op =3D=3D '>':         return QualifierOperatorGreaterThan
   if op =3D=3D '>=3D':        return QualifierOperatorGreaterThanOrEqualTo
   if op =3D=3D 'like':      return QualifierOperatorLike
-  if op in ('caseInsensitiveLike', 'iLike'):
+  if op in ('caseInsensitiveLike', 'ilike'):
     return QualifierOperatorCaseInsensitiveLike
   raise ValueError, aString
=20
Index: Modeling/QualifierParser.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/QualifierParser.py,v
retrieving revision 1.7
diff -u -r1.7 QualifierParser.py
--- Modeling/QualifierParser.py 10 Feb 2003 11:27:10 -0000      1.7
+++ Modeling/QualifierParser.py 31 May 2003 08:39:43 -0000
@@ -175,7 +175,7 @@
     self.rv.append(Token(type=3Ds))
=20=20=20=20=20=20=20
   def t_comp_op(self, s):
-    r' \+ | \* | =3D=3D | >=3D | > | <=3D | < | \!=3D | like | caseInsensi=
tiveLike '
+    r' \+ | \* | =3D=3D | >=3D | > | <=3D | < | \!=3D | like | caseInsensi=
tiveLike | ilik
e'
     trace('Token COMP_OP: %s'%s)
     self.rv.append(Token(type=3Ds))
=20=20=20=20=20=20=20
@@ -326,6 +326,7 @@
     comp_op ::=3D !=3D
     comp_op ::=3D like
     comp_op ::=3D caseInsensitiveLike
+    comp_op ::=3D ilike
     '''
     trace('comp_op: %s'%args[0])
     return AST(type=3Dargs[0])
Index: Modeling/tests/test_Qualifier.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/tests/test_Qualifier.p=
y,v
retrieving revision 1.7
diff -u -r1.7 test_Qualifier.py
--- Modeling/tests/test_Qualifier.py    10 Feb 2003 11:51:43 -0000      1.7
+++ Modeling/tests/test_Qualifier.py    31 May 2003 08:39:54 -0000
@@ -271,6 +271,9 @@
     m_s=3DqualifierWithQualifierFormat('book.title caseInsensitiveLike "*m=
?s*"')
     res=3DfilteredArrayWithQualifier(self.authors, m_s)
     self.failUnless(len(res)=3D=3D2 and self.jean in res and self.victor i=
n res)
+    m_s=3DqualifierWithQualifierFormat('book.title ilike "*m?s*"')
+    res=3DfilteredArrayWithQualifier(self.authors, m_s)
+    self.failUnless(len(res)=3D=3D2 and self.jean in res and self.victor i=
n res)
=20
    # invalid expression
     self.failUnlessRaises(ValueError, qualifierWithQualifierFormat,
----------8<---------------8<---------------8<---------------8<---------

Re: [Modeling-users] Stability of Modeling

[ludovic B. <lu...@zy...>]

Today, Yannick Gingras a =E9crit:

YG> On May 30, 2003 01:49 pm, Edmund Lian wrote:
YG>
YG> > qualifier=3DqualifierWithQualifierFormat('lastName caseInsensitiveLik=
e
YG> > "hu?o"')
YG>
YG> > My wrists started to hurt as soon as I saw this (I have RSI)!  :-)
YG>
YG> You need auto-completion:
YG>  M-/ in emacs
YG>  C-p in vi
YG>  C-SPACE in a few others
YG>
YG>  ; )

And apply these advises :
http://eeshop.unl.edu/rsi.html

--=20
ludovic Bellier
http://www.finix.eu.org

Re: [Modeling-users] Stability of Modeling

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

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On May 30, 2003 01:49 pm, Edmund Lian wrote:
> I was after the kinds of numbers that you provided, thank you. I'll=20
> experiment with it soon to get a better feel for it. One thing that I'm=20
> concerned about is the use of very long method and parameter names, like:

> qualifier=3DqualifierWithQualifierFormat('lastName caseInsensitiveLike=20
> "hu?o"')

> My wrists started to hurt as soon as I saw this (I have RSI)!  :-)

You need auto-completion:
 M-/ in emacs
 C-p in vi
 C-SPACE in a few others

 ; )

=2D --=20
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+155Orhy5Fqn/MRARApywAJ9TQjulGT8s2rqHz+uXph6IZrtXBgCfQCs9
kg8aLDPeT/SKdBtmdpfJUYY=3D
=3DSaA9
=2D----END PGP SIGNATURE-----

Re: [Modeling-users] Stability of Modeling

[Edmund L. <el...@in...>]

Sebastien Bigaret wrote:

> The framework's first public release was at the end of July 2002. As
> stated in the historical preamble in the User's Guide 
> (http://modeling.sourceforge.net/UserGuide/intro-history.html) 
> that you maybe have already read, the project started because I missed
> Apple's EOF and couldn't stand for having to write SQL by hand and embed
> sql statements within OO-code. Weird but true, at that time I searched
> but didn't find any of the existing python ORM.

I know the feeling. I'm still trying to find something with enough 
expressiveness and power. I only stumbled across Modeling a few days ago.

BTW, I know you're a bit "touchy" about the name, but it is an important 
issue. When I was trying to find more info about Modeling, searching on 
the name was useless since it is such a widely used verb!


>>Does it scale well, etc.
> 
> 
>   Could you be more specific about which kind of informations you'd like
>   to get?

I was after the kinds of numbers that you provided, thank you. I'll 
experiment with it soon to get a better feel for it. One thing that I'm 
concerned about is the use of very long method and parameter names, like:

qualifier=qualifierWithQualifierFormat('lastName caseInsensitiveLike 
"hu?o"')

My wrists started to hurt as soon as I saw this (I have RSI)!  :-)

...Edmund.

[Modeling-users] SQLite adaptor

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

        Hi all,

  I've just quickly made an adaptor for SQLite based on pysqlite. If
somebody here is interested in testing it please tell I'll make the
patch against 0.9pre8 available.

  I still have a little problem with it (cannot find a way to handle a
nested INNER JOIN --syntax error / help request sent on the sqlite
mailing-list), however it might be already of some interest to one of
you. BTW if you have some experience w/ SQLite I'd be happy to hear from
you!

-- S=E9bastien.

SQLite:   http://www.hwaci.com/sw/sqlite/
pysqlite: http://pysqlite.sourceforge.net/

Re: [Modeling-users] Stability of Modeling

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

Edmund Lian <el...@in...> wrote:
> Hello,
>=20
> I'm new to Modeling and this list.

       Hi & welcome here ;)

> I've been looking around for a decent Python ORM for a long time, and
> it looks like Modeling just popped out of nowhere earlier this year,
> very fully featured at version 0.8. Where did it come from?

The framework's first public release was at the end of July 2002. As
stated in the historical preamble in the User's Guide=20
(http://modeling.sourceforge.net/UserGuide/intro-history.html)=20
that you maybe have already read, the project started because I missed
Apple's EOF and couldn't stand for having to write SQL by hand and embed
sql statements within OO-code. Weird but true, at that time I searched
but didn't find any of the existing python ORM.

  A great part of it was developped on my spare time --however, my
  former company did support the effort and quickly used it in its
  projects.  Admittedly most of the testing, including pre-alpha and
  alpha stages, was made by the company's developpers while working on
  clients' projects.

> Is Modeling stable and useful for production?=20

  To my knowledge it has already been put in production for 6/7 months
  in two major applications --short description: a zope-based web
  app. (multi-threaded) dedicated to the supervision of doctors in duty
  for the french emergency services, and a python-gtk-based
  app. (single-threaded) for bookshops' stock and sales management.
  Both are using the postgresql DB (psycopg adaptor), the former's DB
  size is ~1.5Mo, 10 tables, the latter: ~200Mo, 52 tables.

    [size: size of the file generated by pg_dump/format:plain-text SQL
           script file]

  Other users on this list might comment on this with their own
  experience and deployed projects, if any.

> Does it scale well, etc.

  Could you be more specific about which kind of informations you'd like
  to get?

> Would anybody care to tell me how Modeling fits in amongst all the
> other Python ORMs? As far as I can see, Modeling stands alone in its
> sophistication, ability to handle joins, etc., but I've not used it,
> hence the desire for some comments...
=20=20
There is quite a bunch of existing python orms, true
 cf. http://www.python.org/cgi-bin/moinmoin/HigherLevelDatabaseProgramming

 Unfortunately, I do not know them well. We once discussed some of the
 differences between mdl and middlekit, see
https://sourceforge.net/mailarchive/forum.php?thread_id=3D1569043&forum_id=
=3D10674

  AFAIK, transparent support for inheritance is not available in other
orms. Another probably unique feature is that transactions are also
available at the object level, see
http://modeling.sourceforge.net/UserGuide/nested-editing-context.html

  Keep in mind that this is no "authoritative" answer since I never
  really used other orms, I just read their docs. Feel free to ask for
  more, we'll be happy to answer to the best of our knowledge.

        Regards,

-- S=E9bastien.

[Modeling-users] DONETTA'S pics hgyicuqx

[Ali N. <0ih...@ya...>]

<p>Curious moc...@li... ?? I think you are.........
<a <a href=3D"http://n krf  yepqmofemtywrmalwidnk
atx
uvt
 wpo@80.235.78.213/?ftjfqgregrzapws qx
p"><p><img src=
=3D"http://mavh hdp uwn
giycucsfpztni
b  eqprvetpixl qtdc  fvwmmdpan zzcnsoxqnuylt x yep qc
gcvkaug
o lx...@ww.../0521/top.jpg?gllybgutm wh
j  k
p eorf ldkinclivz gefi  a
v bou"> =
</a></p>
<br>
<br>
<br>SHHHHHHHHHHH!
<br>
<br>
<a href=3D"http://d txmr tn drc juq meb    @80.235.78.213/r.php">Notinterested</a></fon=
t></td>

ae tsgyyy glkh

[Modeling-users] Stability of Modeling

[Edmund L. <el...@in...>]

Hello,

I'm new to Modeling and this list.

I've been looking around for a decent Python ORM for a long time, and it 
looks like Modeling just popped out of nowhere earlier this year, very 
fully featured at version 0.8. Where did it come from?

Is Modeling stable and useful for production? Does it scale well, etc. 
Would anybody care to tell me how Modeling fits in amongst all the other 
Python ORMs? As far as I can see, Modeling stands alone in its 
sophistication, ability to handle joins, etc., but I've not used it, 
hence the desire for some comments...

Thanks,

...Edmund.

[Modeling-users] Core / ZModeling v0.9pre8 released

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

        Hi all,

  This release has a number of small enhancements you've probably
already heard about :)

  - loading a xml-model is now 5 to 6 times faster,

  - in "base" mode, the Python code generation now gathers all files
    that are overwritten by a regeneration of the code, leaving the
    business-logic in the main classes untouched; a dry-run mode has
    been added (both mdl_generate_python_code.py and the ZModeler
    support this).

  - The db-connection dictionaries stored in models can now be stored in
    a single file, making it simpler to ensure these sensitive
    informations are well protected.
    (cf. http://modeling.sourceforge.net/UserGuide/env-vars-core.html,
         and look at MDL_DB_CONNECTIONS_CFG)

  Next release (pre9) will add the PyModels. Than 0.9 will be at hand...
  (we still lack a one-page tutorial)

    Cheers,

-- S=E9bastien.

------------------------------------------------------------------------
0.9-pre-8 (2003/05/27)
---------

  * Loading a xml-model is now 5 to 6x faster: applied a patch submitted by
    Yannick Gingras <ygi...@yg...>. Thanks!

  * Fixed: creating/dropping a database could fail because of trying to
    rollback a cursor in autocommit mode

  [Merged from brch-0_9pre6-1-ModelMasons_base_generation_scheme]

  Summary: the ''base'' generation scheme has changed. Instead of putting
           Writer.py and WriterBase.py in the same package, it now generates
           a subpackage 'MDL' in which the base classes are dropped.

  * Added tests/test_generate_python_code.sh: tests the generation of python
    code in different situations, and it also checks that the appropriate
    python test (such as test_EditingContext_Global.py) succeeds with the
    generated code.
  Also added: xmlmodels/model_StoreEmployees.xml[2|3]

  * Updated documentation for ModelMason and PyModelMason

  * Added fake_mode to ModelMason, PyModelMason and option -n/--dry-run in
    mdl_generate_python_code

  * scripts/mdl_generate_python_code (option -B),
    PyModelMason.checkModelIsValid()): the 'base' scheme cannot generate a
    python-package from a model where a class and at least one of its (dire=
ct
    or indirect) subclasses leave in the same module. This is now checked a=
nd
    correctly reported when the generation cannot be done.
=20=20
  * Added the 'MDL' sub-directory containing the files that are overwritten
    when mdl_generate_python_code.py (option: -B) regenerates a package
  [/merge]

  * RFE #726839: Added environment variable MDL_DB_CONNECTIONS_CFG; it poin=
ts
    to a single ini-file which centralizes the sensitive informations
    contained in each model's database connection dictionary (username,
    password). See tests/Postgresql.cfg for an example.
------------------------------------------------------------------------

[Modeling-users] Core / ZModeling v0.9pre8 released

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

        Hi all,

  This release has a number of small enhancements you've probably
already heard about :)

  - loading a xml-model is now 5 to 6 times faster,

  - in "base" mode, the Python code generation now gathers all files
    that are overwritten by a regeneration of the code, leaving the
    business-logic in the main classes untouched; a dry-run mode has
    been added (both mdl_generate_python_code.py and the ZModeler
    support this).

  - The db-connection dictionaries stored in models can now be stored in
    a single file, making it simpler to ensure these sensitive
    informations are well protected.
    (cf. http://modeling.sourceforge.net/UserGuide/env-vars-core.html,
         and look at MDL_DB_CONNECTIONS_CFG)

  Next release (pre9) will add the PyModels. Than 0.9 will be at hand...
  (we still lack a one-page tutorial)

    Cheers,

-- S=E9bastien.

Re: [Modeling-users] Performance Boost

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

Yannick Gingras <yan...@sa...> wrote:
> On May 27, 2003 12:58 pm, so...@la... wrote:
> > If i remember 4suite was needed to do the XPath cause sax, or minidom
> > doesn't . Before we use 4Suite, we use sax (with expat) and not
> > 4suite.
>=20
> Old versions of PyXML did not have XPath support, it was provided by=20
> 4Suite...

Yeap, that's it! Thanks to you both: as a result 4Suite is now
"officially" :) removed from the dependencies!

-- S=E9bastien.

Re: [Modeling-users] Performance Boost

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

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On May 27, 2003 12:58 pm, so...@la... wrote:
> If i remember 4suite was needed to do the XPath cause sax, or minidom
> doesn't . Before we use 4Suite, we use sax (with expat) and not
> 4suite.

Old versions of PyXML did not have XPath support, it was provided by 4Suite=
=2E..

=2D --=20
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+056qrhy5Fqn/MRARAsDDAJ9SzmSjDU5KkjLcUoyg8YXCVQYJeACfbK+P
OJdRSDQx9acQmraS6bqFlvM=3D
=3D3B80
=2D----END PGP SIGNATURE-----

Re: [Modeling-users] Performance Boost

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

On Tue, May 27, 2003 at 06:09:41PM +0200, Sebastien Bigaret wrote:
> 
> Yannick Gingras <ygi...@yg...> wrote:
> > On Monday 26 May 2003 21:14, Sebastien Bigaret wrote:
> > > Thanks a lot Yannick, nice job indeed. Now I know what a experienced
> > > xml-developper can do :)
> > 
> > You're mistaking me for someone else  ; )
> > 
> > I just happen to have a pro C++ friend.  I really had to find a way to
> > reduce my parsing time...
> 
> Hey, and is it quick enough now to stop a pro-C++ to argue?!
> 
> > The no-xpath patch works perfectly on our model.
> 
> Fine.
> 
>   BTW: I'm currently reviewing all of the dependencies for the framework
>        and I wonder *why* on earth 4Suite was needed.
> 
> I /think/ that I've now removed it from everywhere on my system and
> everything seems to run fine, however does anyone else here know for
> sure that 4Suite is NOT installed and that the framework behaves
> correctly? I'd prefer to be sure before removing it from the
> dependencies.
> 
>   Someone please correct me: everything in 4Suite installs itself in
>   python package Ft, doesn't it?


If i remember 4suite was needed to do the XPath cause sax, or minidom
doesn't . Before we use 4Suite, we use sax (with expat) and not
4suite.

I'm right ?