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

[Modeling-users] Re: Licence issues and a manual corrections

[Ernesto R. <er...@si...>]

Dear S=E9bastien,

I talked with Andy Robinson (CEO of ReportLab) at EuroPython about that. =
His point of view is close to mine, we produce libs and components with =
an open-style licence, so every software developer can use it the she =
likes, but finished applications sometimes should not be free, because =
companies simply install them and want to get free support from the =
'community'. This is not how I want it to be. Software developer fetch =
up the code (and products) and should, of course, give feed back to the =
community (new products, patches, test results, documentation, or =
whatever), but what should end users do? (pay some cash, if possible, so =
you can continue work on your favourite project).

In either way, this is just a point of view. And I want to thank you =
very much to share your magnific work openly with others.

The manual correction:
in section: 2.4.6.2 AFloat says

property   type    defaults to 'string', should be 'float'.

With best regards,
Erny

Re: [Modeling-users] Licence issues

[Matthew P. <pa...@dm...>]

On Tue, 24 Feb 2004, Marcos Dione wrote:

> On Tue, Feb 24, 2004 at 04:15:59PM +0100, Sebastien Bigaret wrote:
> >   So: I'd like to hear from any of you here who thinks the GPL is or
> >   could be a problem for you/your company/your activity (or maybe think
> >   the opposite) --since this has been put on my list and that I plan to
> >   make up my mind soon, it's probably time to speak loud and clear ;)
>
>     I think the stock answer is: LGPL or a double licencing, like qt
> does. those are the simple choices. or you can try to build a new
> license, but try to avoid the errors made by xfree or apache. maybe you
> can also read the slashdot articles and comments and draw your own
> conclusions.


I would definitely caution against writing your own license because of the
legal complexities involved.  The LGPL would, as I understand it, allow
Modeling to be used in commercial apps while insisting that Modeling
itself remain open source.  Apparently the BSD license would allow
this as well. Eric Raymond has a good chapter on the issues
in the Art of Unix Programming:
http://www.faqs.org/docs/artu/ch16s07.html

As a matter of opinion, either LGPL or GPL would work for me.

						Matt

Re: [Modeling-users] Licence issues

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

On Tue, Feb 24, 2004 at 04:15:59PM +0100, Sebastien Bigaret wrote:
>   So: I'd like to hear from any of you here who thinks the GPL is or
>   could be a problem for you/your company/your activity (or maybe think
>   the opposite) --since this has been put on my list and that I plan to
>   make up my mind soon, it's probably time to speak loud and clear ;)

    I think the stock answer is: LGPL or a double licencing, like qt
does. those are the simple choices. or you can try to build a new
license, but try to avoid the errors made by xfree or apache. maybe you
can also read the slashdot articles and comments and draw your own
conclusions.

Re: [Modeling-users] Licence issues

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

        Hi Erny and all,

  I do understand the point: the GPL can be really annoying in a
commercial environment --and in some other situations as well, esp. when
micing different licenses together.  Interestingly, I've been discussing
this point with someone else on a private conversation for a few days,
someone who basically wanted to know why I chose GPL.  I won't go into
much details now, esp. because I've no time today, but at least I
wanted to say I'm seriously considering switching from GPL to a more
permissive, python-like license.

  So: I'd like to hear from any of you here who thinks the GPL is or
  could be a problem for you/your company/your activity (or maybe think
  the opposite) --since this has been put on my list and that I plan to
  make up my mind soon, it's probably time to speak loud and clear ;)

-- S=E9bastien.


"Ernesto Revilla" <er...@si...> wrote:
> Dear Sebasti=E9n,
>=20
> actually, your framework is GPL which means that all software which
> uses modeling has to be GPL. (Is yours also?) Although, we support
> open software (my coworker just wrote a GTK grid with python bindings,
> open for everyone), our actual policy is that all libs should be open,
> but some productivity tools may be comercial. The problem is to
> recover the investment to create basic technologies.
>=20
> Beside the GPL, are there other ways to have a comercial tool (may be
> open source) that includes modeling? (I think either of a comercial
> licence for modeling, or a licence type LGPL or something else.)
>=20
> With best regards,
> Erny

[Modeling-users] Suggestion for user manual

[Ernesto R. <er...@si...>]

Dear S=E9bastien,

(I think, in the last message I didn't put correctly the accent.)

In section 2.3.4: Relationship

In deleteRule:
The entity in your example is not 'Author' but 'Writer'. On the other =
hand, the relationships are called there:
* author  and
* books

not: toAuthor and toBooks.

Perhaps, there could be a clarification of the UML notation, so that the =
behaviour of modeling would be a bit clearer for persons without =
knowledge of UML. I attach it here for your consideration.

Best regards,
Erny


Dear S=E9bastien,

(I think, in the last message I didn't put correctly the accent.)

In section 2.3.4: Relationship

In deleteRule:
The entity in your example is not 'Author' but 'Writer'. On the other =
hand, the relationships are called there:
* author  and
* books

not: toAuthor and toBooks.

Perhaps, there could be a clarification of the UML notation, so that the =
behaviour of modeling would be a bit clearer for persons without =
knowledge of UML. I attach it here for your consideration.

Best regards,
Erny

 

[Modeling-users] Licence issues

[Ernesto R. <er...@si...>]

Dear Sebasti=E9n,

actually, your framework is GPL which means that all software which uses =
modeling has to be GPL. (Is yours also?) Although, we support open =
software (my coworker just wrote a GTK grid with python bindings, open =
for everyone), our actual policy is that all libs should be open, but =
some productivity tools may be comercial. The problem is to recover the =
investment to create basic technologies.

Beside the GPL, are there other ways to have a comercial tool (may be =
open source) that includes modeling? (I think either of a comercial =
licence for modeling, or a licence type LGPL or something else.)

With best regards,
Erny

[Modeling-users] Release 0.9pre17.1

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

        Hi all,

I've just released 0.9pre17.1, which fixes the problem, reported by Jeff
yesterday, making the framework unusable for python2.2 and python2.3
when ZODB is installed. The bug was introduced in the last version.

  I've also taken the opportunity to fix mdl_generate_DB_schema.py so
that it indicates an error when no command are supplied, as reported by
Tom Hallman a few days ago.


-- S=E9bastien.

PS: you do not need to download the full package if you already
    downloaded 0.9pre17, a patch is available at sf.net to convert
    0.9pre17 to 0.9pre17.1:

http://prdownloads.sourceforge.net/modeling/ModelingCore.0.9pre17_to_0.9pre=
17.1.patch?download



------------------------------------------------------------------------
0.9-pre-17.1 (2004/02/22)
-------------------------

  * Fixed bug #902106: impossible to load a model if ZODB is installed.
    NB: useless module Modeling.Persistent removed.

  * Fixed bug #902209: mdl_generate_DB_schema.py silently exiting when no
    commands are provided on the cmdline; this could be variously
    misinterpreted. The script now correctly reports this as an error.
------------------------------------------------------------------------

[Modeling-users] Release 0.9pre17.1

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

        Hi all,

I've just released 0.9pre17.1, which fixes the problem, reported by Jeff
yesterday, making the framework unusable for python2.2 and python2.3
when ZODB is installed. The bug was introduced in the last version.

  I've also taken the opportunity to fix mdl_generate_DB_schema.py so
that it indicates an error when no command are supplied, as reported by
Tom Hallman a few days ago.


-- S=E9bastien.

PS: you do not need to download the full package if you already
    downloaded 0.9pre17, a patch is available at sf.net to convert
    0.9pre17 to 0.9pre17.1:

http://prdownloads.sourceforge.net/modeling/ModelingCore.0.9pre17_to_0.9pre=
17.1.patch?download



------------------------------------------------------------------------
0.9-pre-17.1 (2004/02/22)
-------------------------

  * Fixed bug #902106: impossible to load a model if ZODB is installed.
    NB: useless module Modeling.Persistent removed.

  * Fixed bug #902209: mdl_generate_DB_schema.py silently exiting when no
    commands are provided on the cmdline; this could be variously
    misinterpreted. The script now correctly reports this as an error.
------------------------------------------------------------------------

Re: [Modeling-users] ZModelizationTool Importing into Zope failure

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

"W.J. MacIsaac" <wjm...@uc...> wrote:
> I've gone wrong somewhere, but I'm at a loss as to say how. Can anyone
> diagnose this?
>=20
> Zope runs fine without trying to import the tool.
>=20
> Thanks,
> Jeff
>=20
>=20
> [jeff@shackleton Zope-2.7.0]$ ./bin/runzope
[...]
> Traceback (most recent call last):
>   File "/usr/src/Zope-2.7.0/lib/python/OFS/Application.py", line 654, in =
import_product
>     product=3D__import__(pname, global_dict, global_dict, silly)
>   File "/usr/src/Zope-2.7.0/Products/ZModelizationTool/__init__.py", line=
 28, in ?
>     import ZModelizationTool
>   File "/usr/src/Zope-2.7.0/Products/ZModelizationTool/ZModelizationTool.=
py", line 40, in ?
>     from Modeling.Entity import Entity
>   File "/usr/lib/python2.3/site-packages/Modeling/Entity.py", line 121, i=
n ?
>     class Entity(base_object, XMLCapability, Persistent, KeyValueCoding):
> TypeError: metaclass conflict: the metaclass of a derived class must be a=
 (non-strict) subclass of the metaclasses of all its bases


  My apologies for that, the responsability is defintiely on my side.

Quick fix: edit Entity.py and change the line that says:
      ----
      class Entity(base_object, XMLCapability, Persistent, KeyValueCoding):
      ----
into:
      ----
      class Entity(XMLCapability, Persistent, KeyValueCoding):
      ----

ie: remove 'base_object' from the list of its superclass.


Explanation: the patch for dynamic creation of modules from models which
  is included in 0.9pre17 also included some changes in the base classes
  of classes that are heavily used in the framework (among which:
  Entity), making them subclasses of 'object'. This is because new-style
  classes tends to run quicker then classic-styles. However, when ZODB
  is installed (and this is definitely the case in the ZModeler scope!),
  we get the "TypeError: metaclass conflict" exception for classes
  inheriting from both types.ObjectType and ZODB.Persistent (extension
  class).


I should have detected this but forgot to run the tests with ZODB
installed. This is now integrated into the shell script verifying
releases' integrity, hopefully this won't happen anymore.


  Ticket #902106 has been created accordingly on sf.net. I'll try to
  make a new release ASAP, since this will affect every installation
  where ZODB is in the pythonpath (that's NOT a zope-only issue).

        Thanks for reporting!

-- S=E9bastien.

[Modeling-users] ZModelizationTool Importing into Zope failure

[W.J. M. <wjm...@uc...>]

I've gone wrong somewhere, but I'm at a loss as to say how. Can anyone
diagnose this?

Zope runs fine without trying to import the tool.

Thanks,
Jeff


[jeff@shackleton Zope-2.7.0]$ ./bin/runzope
------
2004-02-21T17:34:27 INFO(0) ZServer HTTP server started at Sat Feb 21 17:34:27 2004
        Hostname: shackleton
        Port: 8080
------
2004-02-21T17:34:27 INFO(0) ZServer FTP server started at Sat Feb 21 17:34:27 2004
        Hostname: shackleton
        Port: 8021
------
2004-02-21T17:34:28 ERROR(200) Zope Could not import Products.ZModelizationTool
Traceback (most recent call last):
  File "/usr/src/Zope-2.7.0/lib/python/OFS/Application.py", line 654, in import_product
    product=__import__(pname, global_dict, global_dict, silly)
  File "/usr/src/Zope-2.7.0/Products/ZModelizationTool/__init__.py", line 28, in ?
    import ZModelizationTool
  File "/usr/src/Zope-2.7.0/Products/ZModelizationTool/ZModelizationTool.py", line 40, in ?
    from Modeling.Entity import Entity
  File "/usr/lib/python2.3/site-packages/Modeling/Entity.py", line 121, in ?
    class Entity(base_object, XMLCapability, Persistent, KeyValueCoding):
TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases
Traceback (most recent call last):
  File "/usr/src/Zope-2.7.0/lib/python/Zope/Startup/run.py", line 49, in ?
    run()
  File "/usr/src/Zope-2.7.0/lib/python/Zope/Startup/run.py", line 19, in run
    start_zope(opts.configroot)
  File "/usr/src/Zope-2.7.0/lib/python/Zope/Startup/__init__.py", line 51, in start_zope
    starter.startZope()
  File "/usr/src/Zope-2.7.0/lib/python/Zope/Startup/__init__.py", line 230, in startZope
    Zope.startup()
  File "/usr/src/Zope-2.7.0/lib/python/Zope/__init__.py", line 46, in startup
    _startup()
  File "/usr/src/Zope-2.7.0/lib/python/Zope/App/startup.py", line 45, in startup
    OFS.Application.import_products()
  File "/usr/src/Zope-2.7.0/lib/python/OFS/Application.py", line 631, in import_products
    import_product(product_dir, product_name, raise_exc=debug_mode)
  File "/usr/src/Zope-2.7.0/lib/python/OFS/Application.py", line 654, in import_product
    product=__import__(pname, global_dict, global_dict, silly)
  File "/usr/src/Zope-2.7.0/Products/ZModelizationTool/__init__.py", line 28, in ?
    import ZModelizationTool
  File "/usr/src/Zope-2.7.0/Products/ZModelizationTool/ZModelizationTool.py", line 40, in ?
    from Modeling.Entity import Entity
  File "/usr/lib/python2.3/site-packages/Modeling/Entity.py", line 121, in ?
    class Entity(base_object, XMLCapability, Persistent, KeyValueCoding):
TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases


------------------------------------------------------------------------------
W.J. MacIsaac
Department of Civil Engineering
University of Calgary
403.210.9783
wjm...@uc...
CCIT 223

Re: [Modeling-users] mdl_generate_DB_schema.py

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

Tom Hallman <hal...@dm...> wrote:
> Hey all,
>=20
>    I'm having some trouble with the mdl_generate_DB_schema.py script. As I
> understand it, the -c (or --stdout) option should send output to stdout, =
as
> opposed to just creating the DB. However, when I run it as such:
>=20
> --------------------
> hallmant@jael:~/Modeling$ ls
> mytest.xml
> hallmant@serv:~/Modeling$ mdl_generate_DB_schema.py -c mytest.xml
>=20
> hallmant@serv:~/Modeling$
> --------------------
>=20
>    You can see that nothing is getting outputted (as far as I can tell.) =
Is
> this a bug in the script or am I doing something wrong?

You're not doing anything wrong: you need to give a command, ie
something to generate. For example,

  hallmant@serv:~/Modeling$ mdl_generate_DB_schema.py -c -TPSF mytest.xml

should give you the sql statements creating the database. See --help for
more options.

  BTW you're also right when suggesting this is a bug, the script should
  at least inform you that a db-generation command is needed, this will
  be fixed in the next release. Thanks for reporting.


Oh, and last: I see you're using a xml model, are you using the ZModeler
or another mean? Did you consider using PyModels instead?  Usually
people tend to think PyModels are easier to create and manipulate,
that's why I'm pointing this out, just in case you didn't notice that
option.


-- S=E9bastien.

[Modeling-users] mdl_generate_DB_schema.py

[Tom H. <hal...@dm...>]

Hey all,

   I'm having some trouble with the mdl_generate_DB_schema.py script. As I
understand it, the -c (or --stdout) option should send output to stdout, as
opposed to just creating the DB. However, when I run it as such:

--------------------
hallmant@jael:~/Modeling$ ls
mytest.xml
hallmant@serv:~/Modeling$ mdl_generate_DB_schema.py -c mytest.xml

hallmant@serv:~/Modeling$
--------------------

   You can see that nothing is getting outputted (as far as I can tell.) Is
this a bug in the script or am I doing something wrong?

~Tom

___________________________________________________________
Tom Hallman                             DiscipleMakers, Inc
hal...@dm...                 http://www.dm.org/~hallmant
531 Brittany Dr * State College * PA * 16803 * 814-861-4591
Go therefore and make disciples of all nations (Matt 28:19)

Re: [Modeling-users] willChange - under the hood

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

        Hi Tom,

Tom Hallman <hal...@dm...> wrote:
> Greetings!
>=20
>    I am just about to start doing some work with Modeling, and I'm very
> excited about its capabilities! It looks very promising, to say the least.
>=20
>    One question I have is on what "willChange" actually does. As I unders=
tand
> it, Modeling captures a single "snapshot" of some fetched rows (objects),=
 and
> whenever "willChange" is called on a particular object's attribute, that
> attribute is made "dirty", such that when "ec.saveChanges()" is called, o=
nly
> "dirty" attributes get updated. Is this accurate?

Absolutely, except one detail: willChange() marks the whole object as
updated (not a particular object's property); the object is then
examined when the EC saves changes. The snapshots are registered in the
central Database object, and when the EC saves changes, the objects that
were marked as updated (the "dirty" ones) are compared to their
snapshots and the observed changes are propagated to the database.

Hence, a "dirty" object that in fact did not change will not cause any
SQL UPDATE to be sent to the database --you can verify that by setting
MDL_ENABLE_DATABASE_LOGGING to "yes" and observing the sql statements
(not) sent to the database. For example, using the AuthorBooks test
model:

>>> from AuthorBooks import Book
>>> from Modeling.EditingContext import EditingContext
>>> ec=3DEditingContext()
>>> b=3Dec.fetch('Book')[0] # get whatever book
>>> b
<AuthorBooks.Book.Book object at 0x85060fc>
>>> b.willChange()
>>> ec.allUpdatedObjects()
[<AuthorBooks.Book.Book object at 0x85060fc>]
>>> ec.saveChanges() # does not send any sql statement to the db
>>> # same if you modify an obj. property then revert to the original value:
... fetched_title=3Db.getTitle()
>>> b.setTitle("this is a new title, not the fetched one")
>>> b.setTitle(fetched_title) # restore the original value
>>> ec.allUpdatedObjects()
[<AuthorBooks.Book.Book object at 0x85060fc>]
>>> ec.saveChanges() # does not send any sql statement to the db either

  Wishing you a nice trip with the framework!)

-- S=E9bastien.

[Modeling-users] willChange - under the hood

[Tom H. <hal...@dm...>]

Greetings!

   I am just about to start doing some work with Modeling, and I'm very 
excited about its capabilities! It looks very promising, to say the least.

   One question I have is on what "willChange" actually does. As I 
understand it, Modeling captures a single "snapshot" of some fetched rows 
(objects), and whenever "willChange" is called on a particular object's 
attribute, that attribute is made "dirty", such that when "ec.saveChanges()" 
is called, only "dirty" attributes get updated. Is this accurate?

   Thanks in advance for any insight.

~Tom

___________________________________________________________
Tom Hallman                             DiscipleMakers, Inc
hal...@dm...                 http://www.dm.org/~hallmant
531 Brittany Dr * State College * PA * 16803 * 814-861-4591
Go therefore and make disciples of all nations (Matt 28:19)

Re: [Modeling-users] limiting the amount of objects retrieved

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

        Hi,

Sebastien Bigaret <sbi...@us...> wrote:
>   The patch #892454 should be applied to v0.9pre16. It adds fetch slices
>   and, as an extra bonus, 'orderBy' parameter to ec.fetch().
>=20
>   It can be found at:
> https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D892454&grou=
p_id=3D58935&atid=3D489337


At the same url, you'll find a brand new patch updated for 0.9pre17.

-- S=E9bastien.

[Modeling-users] Modeling/core v0.9pre17 released

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

        Hi all,

This release consists mainly in bug-fixes, for which you'll find the
details in the full changelog, below.

  Additionally, it should be noted that the default behaviour is now to
  keep the connection to the database opened --see the User's Guide:

    http://modeling.sourceforge.net/UserGuide/env-vars-core.html

  doc. for MDL_TRANSIENT_DB_CONNECTION for details. Remember that the
  file MIGRATION contains any details that should be taken into account
  when updating the framework to a newer version.

(Support for sql datatype DOUBLE was added to MySQL adaptor)

  Last, the two patches for batch-fetching relationships and for the
  dynamic creation of modules have been integrated, but will be
  officially announced in the next release, when the related
  documentation is written.

Thanks to all for the patches, the bug reports, the tests and the
suggestions!

-- S=E9bastien.



------------------------------------------------------------------------
0.9-pre-17 (2004/02/17)
-----------------------
  * Integrated patch #814055: Dynamic creation of packages/modules/classes.
    Not publicly announced, it is not documented yet.  Till then, the file
    doc/README.dynamic.txt contains further details.

  * MySQL:

    - added DOUBLE to the list of supported SQL types

    - fixed the generation of primary keys: two threads could get the same =
id

  * Applied patch #771009: DatabaseContext.batchFetchRelationship()
    Not publicly announced because it's not documented yet --and there a ne=
ed
    for a more user-friendly API at the EditingContext level!

  * ObserverCenter: internals changed: no more variables or functions whose
    names are surrounded by double-underscores (these names are normally
    reserved for python use)

  * Updated the files to conform to PEP-0263: source encoding is iso-8859-1

  * Fixed SortOrdering.sortOrderingsWithString()

  * Added missing Modeling.__version__, thanks to John Lenton for noticing.

  * Env. variable MDL_PERMANENT_DB_CONNECTION is now deprecated and has no
    effect anymore. It has been replaced by MDL_TRANSIENT_DB_CONNECTION whi=
ch
    has the inverse semantics --see the User's Guide, appendix Environment
    Variables, for details.

  * Fixed bug #880862 using a patch submitted by John Georgiadis (thanks!):
    XML exported under py2.3 cannot be imported back because of boolean val=
ues
    'True' and 'False' not properly handled.

  * MySQL: the model's connection dictionary may now give a specific port to
    connect to.

  * Relationship.py: added __ne__ (for python 2.1 and 2.2), fixed
    FlattenedRelationship.__eq__

  * Fixed bug #862182: Validation refusing valid relations between objects
    (TODO: tests units for this)

  * Fixed bug #861048: Invalid FK constraints in generated DB schema

    Added scripts/bug861048.py that you can run against your model to check=
 if
    the corresponding generated database schema was affected by the bug. If=
 it
    is, the script will tell you what should be done to fix it.

  * Fixed bug #857803: mysql: invalid generated sql for complex qualifiers
    --some qualifiers led to invalid SQL when fetching, causing SyntaxError.

  * Fixed bug #847212: qualifier IN does not handle correctly strings (stri=
ngs
    were not quoted as they should be)

  * Fixed bug #854630: an empty qualifier string made ec.fetch() fail

  * Fixed bug #813297: mdl_generate_db_schema fails for SQLite and -A (fixed
    in 0.9pre16 but it was not announced)


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

[Modeling-users] converting object into raw

[John L. <jo...@vi...>]

Maybe this is in the user manual somewhere, but I can't find it, and
neither can google :(

How do I convert an object back into its "raw" form?

I need this because, in a MVC framework we are working on (=ABCimarr=F3n=BB,
spanish for maverick---and other things), I have a "search"
widget. This widget knows nothing about Modeling, but the controller
can arrange it such that it feeds off of modeling's "raw" objects, or
rows, and thus is much much faster than otherwise. The widget knows it
has an internal representation of the objet it is showing and it has a
series of parsers/printers (provided by the controller--something like
special-purpose delegates) to convert it to/from the external
representation the controller wants; in the parser, it's simply a
question of calling faultForRawRow(). How do I get the printer?

--=20
John Lenton (jo...@vi...) -- Random fortune:
=A1Qu=E9 amable cosa es el hombre cuando es verdaderamente hombre!
		-- Menandro. (343-290 A.C.) Fil=F3sofo griego.=20

Re: [Modeling-users] Re: converting object into raw

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

John Lenton <jo...@vi...> wrote:
> Got it: obj.snapshot_raw(), right?
> 

Absolutely! Be sure to read its documentation for the
special cases that can happen with primary keys and
foreign keys.

-- Sébastien.

[Modeling-users] Re: converting object into raw

[John L. <jo...@vi...>]

Got it: obj.snapshot_raw(), right?

-- 
John Lenton (jo...@vi...) -- Random fortune:
What has roots as nobody sees,
Is taller than trees,
Up, up it goes,
And yet never grows?

Re: [Modeling-users] specifying objects' class

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

John Lenton <jo...@vi...> wrote:
> On Tue, Feb 10, 2004 at 04:57:02PM -0300, John Lenton wrote:
> >=20
> > hmm... it isn't clear to me that this is always what you want;
> > currently we're using (in an unrelated field) a linearization of that
> > graph into
> >=20
> >     Employee <| Person <| EmployeeBase <| PersonBase
> >=20
> > although I can see that in this case you are (on first sight at least)
> > correct. However, no matter what is expected, it is exactly what the
> > C3 MRO in python 2.3 does. If you want your behaviour, all you have to
> > do is declare Employee as
> >=20
> >     class Employee(EmployeeBase, Person)
> >=20
> > whereas if you want the other behaviour you declare it as
> >=20
> >     class Employee(Person, EmployeeBase)
>=20
> after discussing it with Federico (Heinz) I realized I wasn't being
> particularly clear on this point, so, at risk of boring you all to
> death over a subject you care little about, I'll expand on this a bit.
>=20
> First, Federico understood that S=E9bastien is suggesting that the
> EmployeeBase class must explicitely inherit from Person, which is
> seems odd to me; could you (S=E9bastien) clarify that? What I understood
> you to mean was that the EmployeeBase MRO was as you described. As one
> would never instanciate *Base objects, all is well.

I only meant to say that the single-inheritance "approach":

    Emp -> EmpBase -> Person -> PersonBase

is the one that is used when you generate python code with the mdl
script, so in a way Federico understood me right ;) but I think I was
not clear myself in what I wrote.

  The fact is that while py2.3 behaves as "expected", py2.2 does
  not. You can refer e.g. to http://www.python.org/2.3/mro.html, section
  Bad Method Resolution Orders. In fact, I did not want to << damage my
  brain >> to make sure that the scripts behaves as expected for py2.1,
  2.2 and 2.3, so I just made it simple. Hence, the single-inheritance
  approach.

Then, to make it clear :)

  - noone will probably ever want to instanciate *Base objects, right,

  - so this is equivalent to stating that the Employee MRO is:
    EmployeeBase, Person, PersonBase

  - the generated code is less flexible than using py2.3
    multiple-inheritance, but it ensures that the MRO is the same for
    py2.1, 2.2 and 2.3 no matter how deep the inheritance hierarchy can
    be (the deeper it is, the worse the brain damage can be when
    thinking of MRO for all thos pythons :)

> and now for something completely the same:
>=20
>     class PersonBase(object):
>         pass
>     class EmployeeBase(PersonBase):
>         pass
>     class Person(PersonBase):
>         pass
>     class Employee(EmployeeBase, Person):
>         pass
>     print '       Person MRO:', [i.__name__ for i in Person.mro() ]
>     print '     Employee MRO:', [i.__name__ for i in Employee.mro() ]
>     class Employee(Person, EmployeeBase):
>         pass
>     print 'Alt. Employee MRO:', [i.__name__ for i in Employee.mro() ]
>=20
> just to be clear, IMHO the first way is the right way to do it if you
> know the subclasses will never want to override the superclass. This
> is the case of concrete classes in a templated abstract factory, for
> example. The second way is probably what you want most other times.
> In both cases all bets are off if you ever instanciate a *Base.
>=20
> Clearer?

Absolutely! However, the code generated with the base scheme is minimal:
it defines entityName() plus the getters/setters for attributes and
relationships, and these methods are almost never overriden in
superclasses. So my opinion is finally that, *in the scope of the base
classes needed by the mdl framework*, this does not really make much
difference --tell me if I'm still missing an important point.

-- S=E9bastien.


> John Lenton (jo...@vi...) -- Random fortune:
> Is that really YOU that is reading this?

Is that really YOU asking this?-)

Re: [Modeling-users] specifying objects' class

[John L. <jo...@vi...>]

On Tue, Feb 10, 2004 at 04:57:02PM -0300, John Lenton wrote:
>=20
> hmm... it isn't clear to me that this is always what you want;
> currently we're using (in an unrelated field) a linearization of that
> graph into
>=20
>     Employee <| Person <| EmployeeBase <| PersonBase
>=20
> although I can see that in this case you are (on first sight at least)
> correct. However, no matter what is expected, it is exactly what the
> C3 MRO in python 2.3 does. If you want your behaviour, all you have to
> do is declare Employee as
>=20
>     class Employee(EmployeeBase, Person)
>=20
> whereas if you want the other behaviour you declare it as
>=20
>     class Employee(Person, EmployeeBase)

after discussing it with Federico (Heinz) I realized I wasn't being
particularly clear on this point, so, at risk of boring you all to
death over a subject you care little about, I'll expand on this a bit.

First, Federico understood that S=E9bastien is suggesting that the
EmployeeBase class must explicitely inherit from Person, which is
seems odd to me; could you (S=E9bastien) clarify that? What I understood
you to mean was that the EmployeeBase MRO was as you described. As one
would never instanciate *Base objects, all is well.

and now for something completely the same:

    class PersonBase(object):
        pass
    class EmployeeBase(PersonBase):
        pass
    class Person(PersonBase):
        pass
    class Employee(EmployeeBase, Person):
        pass
    print '       Person MRO:', [i.__name__ for i in Person.mro() ]
    print '     Employee MRO:', [i.__name__ for i in Employee.mro() ]
    class Employee(Person, EmployeeBase):
        pass
    print 'Alt. Employee MRO:', [i.__name__ for i in Employee.mro() ]

just to be clear, IMHO the first way is the right way to do it if you
know the subclasses will never want to override the superclass. This
is the case of concrete classes in a templated abstract factory, for
example. The second way is probably what you want most other times.
In both cases all bets are off if you ever instanciate a *Base.

Clearer?

--=20
John Lenton (jo...@vi...) -- Random fortune:
Is that really YOU that is reading this?

Re: [Modeling-users] specifying objects' class

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

John Lenton <jo...@vi...> wrote:
> On Tue, Feb 10, 2004 at 04:28:22PM +0100, Sebastien Bigaret wrote:
> > [...]
> >   rather you want:
> >=20
> >     Employee <|-- EmployeeBase <|-- Person <|-- PersonBase
> >=20
> >   so that Employee inherits from the business-logic defined in Person,
> >   as expected.
>=20
> hmm... it isn't clear to me that this is always what you want;
> currently we're using (in an unrelated field) a linearization of that
> graph into
>=20
>     Employee <| Person <| EmployeeBase <| PersonBase
>=20
> although I can see that in this case you are (on first sight at least)
> correct. However, no matter what is expected, it is exactly what the
> C3 MRO in python 2.3 does. If you want your behaviour, all you have to
> do is declare Employee as
>=20
>     class Employee(EmployeeBase, Person)
>=20
> whereas if you want the other behaviour you declare it as
>=20
>     class Employee(Person, EmployeeBase)
>=20
> unfortunately this only applies to new style classes as of python 2.3;
> I'm not certain the (hackish) MRO in 2.2 DWIMs.

Fine, no problem! I only wanted to point out the fact that Employee
should inherit from both EmployeeBase and Person (and additionally, the
generated code works for py2.1, 2.2 and 2.3, so I used strict
single-inheritance).


> new-style classes would be nice for several reasons, not only
> performance. For starters, the fact that you can query the MRO and use
> super(), makes multiple inheritance manageable.
>=20
> By the way, did you compare the speed of your metaclass approach to an
> exec?

  Sorry, I'm afraid I do not understand what "comparing to an exec"
  means, could you be more explicit?

-- S=E9bastien.

Re: [Modeling-users] specifying objects' class

[John L. <jo...@vi...>]

On Tue, Feb 10, 2004 at 04:28:22PM +0100, Sebastien Bigaret wrote:
> 
>   That's the reason why the -B switch exists in the script
>   mdl_generate_python_code.py ;)  

Oops, I didn realize that was what it was for :-/

> A little remark: this is a little different than just inheriting from
> the mdl-generated class: when inheritance comes in, e.g. for Employee
> deriving from Person, you don't want to have:
> 
>     Employee <|-- EmployeeBase
>                       ^
>                      /_\
>                       |
>                       |
>       Person <|-- PersonBase.
> 
>   rather you want:
> 
>     Employee <|-- EmployeeBase <|-- Person <|-- PersonBase
> 
>   so that Employee inherits from the business-logic defined in Person,
>   as expected.

hmm... it isn't clear to me that this is always what you want;
currently we're using (in an unrelated field) a linearization of that
graph into

    Employee <| Person <| EmployeeBase <| PersonBase

although I can see that in this case you are (on first sight at least)
correct. However, no matter what is expected, it is exactly what the
C3 MRO in python 2.3 does. If you want your behaviour, all you have to
do is declare Employee as

    class Employee(EmployeeBase, Person)

whereas if you want the other behaviour you declare it as

    class Employee(Person, EmployeeBase)

unfortunately this only applies to new style classes as of python 2.3;
I'm not certain the (hackish) MRO in 2.2 DWIMs.

>   Shortly said, this means no code-generation, with the ability to just
>   define your business logic, with the mdl-specific stuff automatically
>   generated at runtime (you'll want to use the metaclass approach
>   then).  Additionally, new-style classes makes things run quicker ;)
>   Note that while this is not integrated into the main trunk yet, this
>   will shortly be. In fact, it should already be there, if only I have
>   had the time for it...

new-style classes would be nice for several reasons, not only
performance. For starters, the fact that you can query the MRO and use
super(), makes multiple inheritance manageable.

By the way, did you compare the speed of your metaclass approach to an
exec?

-- 
John Lenton (jo...@vi...) -- Random fortune:
The early worm gets the late bird.

[Modeling-users] User's Guide in Microsoft HTML Help (chm) format

[Axel K. <ax...@ko...>]

hi all,

i'm a long time Apple WebObjects developer having started with Python 
only recently. i'm glad i found Modeling - thanks for bringing the great 
EOF to Python!

while getting started with Modeling, i found the User's Guide in HTML / 
PDF format a little slow for fast reference and browsing. that's why i 
made it into chm format, which allows fast offline browsing and fulltext 
searching under windows. i find this quite comfortable and thought 
others might too, so i put this up on my chm site: http://chm.kollm.org/ 
. feel free to download, use, and include into the package.

feedback appreciated.

-- 
ax

The secret of success is sincerity. Once you can fake that you've got it 
made. - Jean Gieraudoux

Re: [Modeling-users] specifying objects' class

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

        Hi,

  Your claim is understandable, and indeed, even when using cvs,
frequent re-generation of modules and thus, frequent merge to keep the
busineess logic in generated files can be a real pain.

  That's the reason why the -B switch exists in the script
  mdl_generate_python_code.py ;)  Extracted for the --help:

<< 'base' scheme: adds a sub-module 'MDL' within the generated package. All
       files within MDL/ are ALWAYS overwritten when the python code is
       regenerated, while others (in the root package) are never overwritten
       if they exist.  This is probably the one you want to use if your mod=
el
       changes often. >>

So with the 'base' generation scheme you'll be able to have the business
logic in a module with the generated stuff in an other one, separated,
just as you describe (except that you'll get the business logic in
package 'luca', and the mdl stuff in sub-package 'luca.MDL').

  About the point on how classes are retrieved at run-time: this is
  described here:
  http://modeling.sourceforge.net/UserGuide/faq-change-class-location.html
  This basically mean that the classes are searched from the information
  enclosed in the model --and the model at runtime needs not be the
  exact same one than the model that is used for generation (esp.
  regarding the package, module and class' names).

A little remark: this is a little different than just inheriting from
the mdl-generated class: when inheritance comes in, e.g. for Employee
deriving from Person, you don't want to have:

    Employee <|-- EmployeeBase
                      ^
                     /_\
                      |
                      |
      Person <|-- PersonBase.

  rather you want:

    Employee <|-- EmployeeBase <|-- Person <|-- PersonBase

  so that Employee inherits from the business-logic defined in Person,
  as expected.


Last, you might be interested in testing the dynamic creation of
classes. It is available through patch #814055 at:
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D814055&group_=
id=3D58935&atid=3D489337

and has been discussed there:
https://sourceforge.net/mailarchive/forum.php?thread_id=3D3151927&forum_id=
=3D10674
https://sourceforge.net/mailarchive/forum.php?thread_id=3D3233626&forum_id=
=3D10674
https://sourceforge.net/mailarchive/forum.php?thread_id=3D3239464&forum_id=
=3D10674

  Shortly said, this means no code-generation, with the ability to just
  define your business logic, with the mdl-specific stuff automatically
  generated at runtime (you'll want to use the metaclass approach
  then).  Additionally, new-style classes makes things run quicker ;)
  Note that while this is not integrated into the main trunk yet, this
  will shortly be. In fact, it should already be there, if only I have
  had the time for it...

-- S=E9bastien.


John Lenton <jo...@vi...> wrote:
> Hi all again.
>=20
> We'll be using Modeling for a large(ish) database shortly, and we'd
> like to have to make minimal changes to the generated files, to
> minimize the work required upon a schema change, given that we'll
> probably have a lot of them during the initial developement.
>=20
> In other words, we'd like to be able to put the business logic in one
> tree ('luca', for example), and have the Modeling stuff in another
> tree ('mdl'), with any given class in luca inheriting from its par in
> mdl. That's pretty easy to do, except that we're concerned that things
> like
>=20
>    person.getAddresses()
>=20
> (to borrow from Sample) would return objects from the 'mdl' tree, and
> not our own.
>=20
> Maybe we're just being too lazy, but we fear that, if we don't find a
> way to do this at least semi-automagically, the worked involved will
> be tedious, and thus error-prone.
>=20
> --=20
> John Lenton (jo...@vi...) -- Random fortune:
> 25 de Diciembre, Doom, Doom, Doom.