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

Re: [Modeling-users] N-tier development and modeling

[Federico H. <fh...@vi...>]

On Tue, 2004-03-09 at 19:35, Matthew Patton wrote:
> 	Tom Hallman and I work together, so I speak for both of
> us.  Numerous comments below:

Matt,

I think I understood what you were saying, but obviously you didn't
quite understand my response, which is my fault, of course. You will
find numerous references to NeXTstep and OpenStep in the Modeling
mailing list, as many of us come from that background, and Modeling
itself is a loose reimplementation of EOF (a technology first released
as part of NeXTstep) in Python.

Now, the code that you included would work quite differently in the
NeXTstep environment, for instead of doing the CORBA thing, we'd just
ask a server for a remote editing context. The local process would get a
proxy object, that works like it's local, but in fact forwards all
requests to a real editing context that lives in the server. We'd then
query the database using this editing context, instantiating objects in
the server, for which the Distributed Objects mechanism would create
proxies in the local address space. The whole IPC thing then happens
behind the scenes (aside from a few memory deallocation issues, the
programmer thinks he's dealing with local objects --- we can later argue
whether this is good or not).

My point was that, given that Modeling is an EOF reimplementation, it
might be rewarding to explore the possibilities of using something that
replicates the Distributed Objects functionality to achieve your goals.
Marcos pointed out in the list that Pyro might be such a beast...

Regards,

	Fede

--=20
GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key BD02C6E0
Key Fingerprint: 04F4 08C5 14B7 2C3D DB21  ACF8 6CF5 0B0C BD02 C6E0

Re: [Modeling-users] N-tier development and modeling

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

Hi,
        Tom Hallman and I work together, so I speak for both of
us.  Numerous comments below:

On Sun, 7 Mar 2004, Federico Heinz wrote:

> On Thu, 2004-03-04 at 18:06, Tom Hallman wrote:
> >    Here is the situation: my colleagues and I are attempting to put
together
> > a framework using an N-tier methodology, with the client software
> > interfacing to the server/database backend via remote procedure calls
(RPC).
> > For us, Modeling will serve as a large part of that backend, with an
API
> > written overtop. The client will make calls to this API, and all will
be
grand.
>
> Maybe I'm missing someting here... ?but are you sure that this ought to
> be solved in Modeling itself? I can't help but refer to Modeling's
> ancestor: EOF within OpenStep. In OpenStep, you would use EOF to get
> object/relational persistence, and if you wanted to do n-tier deplyment
> you'd resort to Distributed Objects, which were orthogonal to EOF (i.e.
> any app could use either one, or both, or none).
>
> So maybe what you are looking for is not a Modeling extension, but a
> network-transparent message passing system for Python, which can be used
> together with Modeling?
>

If I understand you correctly, I think you are talking about a similar
solution as the one Tom is proposing originally.  To rephrase our idea, it
is to have to main components: a server and and a client, where the server
provides core data-accessing and data-manipulating functions, and the
client handles the interface to the user and the appropriate calling of
the functions on the server.  For example, if a person had entered their
contact information through a web form, the client code to take that code
and save it to the server would be (rough sketch, sorry I don't know
python or modeling intimately yet):

  # None of the following objects are explicitly related to Modeling

  # Set the form data
  address = Address()
  address.setCity(formData["city"])
  address.setState(formData["state"])
    # etc.

  person = Person()
  person.setAddress(address)
  address.setPerson(person)

  # Initialize connection to the application server (this would be done
  # once somewhere at the beginning of the client's initialization)
  appServer = new AppServer(host="http://www.myappserver.com",
                            protocol=XML_RPC,
                            auth=userObj)

  # Call add on the object PersonContainer, with person as the argument
  # This is a "business logic" method, and may be the sort of transparent
  # message-passing interface you were mentioning
  appServer.PersonContainer.add(person)


On the server side (this would be served up with Zope)

class PersonContainer(ContainerBase):
  def add(self, person):
    """ This method would likely be abstracted, but I wrote it out for
        the example.  Here is where the Modeling code comes in.
        One note: this person object *IS* a modeling-derived enterprise
        object.  The translation from a generic object on the client side
        to a modeling object on the server side is a function of the
        framework we are developing.
    """

    self.ec.insert(person)
    self.ec.saveChanges()


I hope this example is helpful and makes sense.  It is our hope that by
separating out these common "business methods", that we can write numerous
different kinds of clients (web client for a public interface, gtk client
for an administrative interface) that will all utilize the same set of
business methods.  Also, we can have the Application Server serve as a
common point for numerous kinds of clients to go to in order to access a
number of different data sources (LDAP servers, global
configuration files, and of, course, Modeling-accessed DB's).
        I would be interested in any comments you all have as to how we
are going about doing this n-tiered approach and utilizing Modeling.  As
far as we can tell, the only part of Modeling we lose is its faulting
capabilities on the client side.  But the net gain of not having to write
any SQL, not having to care what kind of DB we are accessing, not having
to worry about locking or transactions are all enormous benefits that
Modeling gives us.

                                                Thanks,
                                                Matt

Re: [Modeling-users] N-tier development and modeling

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

User-Agent: Mutt/1.3.28i

On Sun, Mar 07, 2004 at 09:51:08PM +0000, Federico Heinz wrote:
> So maybe what you are looking for is not a Modeling extension, but a
> network-transparent message passing system for Python, which can be used
> together with Modeling...

    ... just like pyro?

Re: [Modeling-users] N-tier development and modeling

[Federico H. <fh...@vi...>]

On Thu, 2004-03-04 at 18:06, Tom Hallman wrote:
>    Here is the situation: my colleagues and I are attempting to put toget=
her=20
> a framework using an N-tier methodology, with the client software=20
> interfacing to the server/database backend via remote procedure calls (RP=
C).=20
> For us, Modeling will serve as a large part of that backend, with an API=20
> written overtop. The client will make calls to this API, and all will be =
grand.

Maybe I'm missing someting here... =BFbut are you sure that this ought to
be solved in Modeling itself? I can't help but refer to Modeling's
ancestor: EOF within OpenStep. In OpenStep, you would use EOF to get
object/relational persistence, and if you wanted to do n-tier deplyment
you'd resort to Distributed Objects, which were orthogonal to EOF (i.e.
any app could use either one, or both, or none).

So maybe what you are looking for is not a Modeling extension, but a
network-transparent message passing system for Python, which can be used
together with Modeling?

	Fede

--=20
GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key BD02C6E0
Key Fingerprint: 04F4 08C5 14B7 2C3D DB21  ACF8 6CF5 0B0C BD02 C6E0

[Modeling-users] ECs synchronization and optimistic locking [was: Re: Another question about sessions and EditingContexts]

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

        Hi all,

  I've just uploaded a patch (#911567) for ECs synchronization upon
  saveChanges(), and for optimistic locking.

https://sf.net/tracker/index.php?func=3Ddetail&aid=3D911567&group_id=3D5893=
5&atid=3D489337


This is alpha software:

  * For now, ECs synchronization works for updated objects, not deleted
    ones, and it does not work for nested ECs.

  * Optimistic locking is implemented and works well, but it's not been
    heavily tested.

The patch is shipped with a new test, test_EC_optimistic_locking.py,
which hopefully demonstrates what can be expected from these new
features.

  Bug/error reports will be preferably directed to the corresponding
sf's ticket #911567, and discussions, questions, etc. about the new
feature can take place here on the mailing-list.  Thanks in advance to
those who will have some time to test the patch!

-- S=E9bastien.

[Modeling-users] Sample code

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

Greetings all,

   I've been reading over the Modeling User's Guide, browsing through the 
sample code, and mulling over the user list emails, and I've come to a 
conclusion. I think what would really benefit me is to be able to look at 
some "production-level" source code. I'd really love to see examples of how 
Modeling is practically used.

   Could any of you offer some code that you yourself have written? I don't 
need to see an entire app or even the underlying database, but to see a 
Model and how an app uses that model would be exceptionally beneficial to me 
(and probably other "new" users as well!)

   Many thanks for anything you can offer!

Yours,
   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] N-tier development and modeling

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

        Hi Tom and all,

Tom Hallman <hal...@dm...> wrote:
> Greetings to all,
>=20
>    It is my hope to draw from the experience and expertise of those among=
 you
> who are more familiar with Modeling than I.
>=20
>    Here is the situation: my colleagues and I are attempting to put toget=
her a
> framework using an N-tier methodology, with the client software interfaci=
ng to
> the server/database backend via remote procedure calls (RPC). For us, Mod=
eling
> will serve as a large part of that backend, with an API written overtop. =
The
> client will make calls to this API, and all will be grand.

Nice!

>    The problem we are having is that of maintaining state between the ser=
ver
> and the client. For example, if we fetch a set of Person objects to be
> displayed on the client, and then want to perform a delete on one particu=
lar
> Person object, how do we know which Person to delete? Modeling seems to w=
ork
> wonderfully up to where there is no RPC necessary, but once we add a split
> over the RPC interface, Modeling seems to lack a natural way to refer to
> objects across that divide.
>=20
>    One thought we had is to set the primary (and foreign?) keys as class
> properties, such that we can refer to them across RPCs. This is somewhat =
of a
> hybrid of Modeling and the old-fashioned "use the primary key to get what=
 we
> want" method.
>=20
>    Any thoughts on this matter would be greatly appreciated! Thanks so mu=
ch
> for your time.

Working with PKs and FKs would work, but it is definitely not the
cleaniest way to identify objects wrt the framwork.  There is a
dedicated component for that purpose: the objects' GlobalID (it can be
accessed through obj.globalID() or by asking the EC for the
globalIDForObject()); a GlobalID is a unique identifier for an object/a
row inside a framework.

  Two different kinds of GlobalIDs exist:

- KeyGlobalIDs identify objects that exists in the database, and
  uniquely identify such an object in whatever EditingContext.

- TemporaryGlobalID uniquely identifies a new object that is not saved
  in the database yet.  Because the objects is not saved, such an
  globalID can identify the object only in its referring EC, or in one
  of its children.

Both can be easily marshalled/unmarshalled, e.g. transformed to strings
and back to GlobalIDs; for example, a KeyGlobalID can be rebuilt from
its entityName() (string) and its keyValues() (dictionary).

  Last, given that you have a gid, you get the corresponding object in a
  EC simply by calling: obj=3Dec.faultForGlobalID(gid, ec)

Does this fulfill your needs?

I still have a question: will you also have an EC on the remote-side?
I'm asking this, because if this is the case the synchronization of the
client's EC and the server's one could be more complicated then simply
identifying objects by their globalIDs and passing some of their changed
attributes. And since I'm currently working on synchronization between
ECs and optimistic locking (working well, I think a first draft wil be
available this week-end), maybe I could also begin to think of such a
"remote" synchronization, esp. if you have a use-case and can consider
testing it in your own app.

-- S=E9bastien.

[Modeling-users] N-tier development and modeling

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

Greetings to all,

   It is my hope to draw from the experience and expertise of those among 
you who are more familiar with Modeling than I.

   Here is the situation: my colleagues and I are attempting to put together 
a framework using an N-tier methodology, with the client software 
interfacing to the server/database backend via remote procedure calls (RPC). 
For us, Modeling will serve as a large part of that backend, with an API 
written overtop. The client will make calls to this API, and all will be grand.

   The problem we are having is that of maintaining state between the server 
and the client. For example, if we fetch a set of Person objects to be 
displayed on the client, and then want to perform a delete on one particular 
Person object, how do we know which Person to delete? Modeling seems to work 
wonderfully up to where there is no RPC necessary, but once we add a split 
over the RPC interface, Modeling seems to lack a natural way to refer to 
objects across that divide.

   One thought we had is to set the primary (and foreign?) keys as class 
properties, such that we can refer to them across RPCs. This is somewhat of 
a hybrid of Modeling and the old-fashioned "use the primary key to get what 
we want" method.

   Any thoughts on this matter would be greatly appreciated! Thanks so much 
for your time.

Yours,
   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] Database adaptors?

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

        Hi Fede,

Federico Heinz <fh...@vi...> wrote:
> We're in contact with a prospective Modeling user. For reasons I'd
> rather not go into (my doctor is worried about my blood pressure), these
> people are likely to want to use it with DB2, for which no adaptor layer
> is available yet.
>=20
> This would be a nice opportunity for us to contribute said adaptor layer
> to Modeling. I've taken a brief look at the available layers, and they
> all seem pretty short and straightforward. Before attempting a go at it,
> though, I'd like to ask the people who have written the other adaptors
> whether there are any pitfalls to avoid

 I can speak for the people who have written the other adaptors ;)

Yes, as you already observed it, writing a db adaptor is not really a
problem given that the python adaptor exists, and that the db does not
show too much differences wrt the SQL standards. As an example, I can
cite mysql, whose earlier version did not accept INNER JOINS, or Oracle
who requires a special statement to handle dates as expected.

  Now the best (and/or quicker) way to write a new adaptor is to derive
  it from an existing one --and, of course, to use the 3 scripts
  test_EC_Global.py, test_Global_Inheritance.py and
  test_EC_ParentChild.py to test it.  Integration of a new adaptor in
  these scripts should not be a problem: add an argument to '-d', and
  write a new configuration file, say, DB2.cfg.

Last and to be complete, as you probably already noticed when looking at
other adaptors, the AbstractDBAPI2Adaptor layer implements all common
things needed by concrete adaptors relying on a DB-API 2.0 compliant
python adaptor.

> [asking about] what a reasonable time
> estimate for writing the adaptor would be.

I'd say one to two days if you're already familiar with the db and the
corresponding python adaptor.

  I'd be really pleased if you could find some time to develop a new
  adaptor, and would happily integrate it into the framework! And, of
  course, I'll be there if you need more details during the
  dev. effort... to help you keep your blood pressure between reasonable
  values ;)

BTW, we could also take this opportunity to start writing a draft of a short
document on "how to derive a new adaptor".

-- S=E9bastien.

[Modeling-users] Database adaptors?

[Federico H. <fh...@vi...>]

We're in contact with a prospective Modeling user. For reasons I'd
rather not go into (my doctor is worried about my blood pressure), these
people are likely to want to use it with DB2, for which no adaptor layer
is available yet.

This would be a nice opportunity for us to contribute said adaptor layer
to Modeling. I've taken a brief look at the available layers, and they
all seem pretty short and straightforward. Before attempting a go at it,
though, I'd like to ask the people who have written the other adaptors
whether there are any pitfalls to avoid, and what a reasonable time
estimate for writing the adaptor would be.

	Fede

--=20
GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key BD02C6E0
Key Fingerprint: 04F4 08C5 14B7 2C3D DB21  ACF8 6CF5 0B0C BD02 C6E0

Re: [Modeling-users] Another question about sessions and EditingContexts (sorry)

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

        Hi,

Ernesto Revilla <er...@si...> wrote:
> Dear S=E9bastien,
>=20
> Yes, actually I have time to do some testing in a test environment (no pr=
oduction) with sqlite and Postgresql. (And I'm sorry I couldn't help you wi=
th python metaclasses in the past.) I'm also very interested in optimistic =
locking.=20

Ok, thanks, such a feature needs to be double-checked, and more :)

  I began working on it yesterday evening, and hopefully we'll have a
first draft in the coming days.  The first conclusion to which I've come
is that optimistic locking is much easier to implement than the
synchronizing of ECs!  The second one is that the first implementation
will be a proof of concept, and won't work for child ECs. I'll let you
know when the first patch is available.

-- S=E9bastien.

Re: [Modeling-users] Another question about sessions and EditingContexts (sorry)

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

Dear S=E9bastien,

Yes, actually I have time to do some testing in a test environment (no =
production) with sqlite and Postgresql. (And I'm sorry I couldn't help =
you with python metaclasses in the past.) I'm also very interested in =
optimistic locking.=20

With best regards,=20
Erny



----- Original Message -----=20
From: "Sebastien Bigaret" <sbi...@us...>
To: "Ernesto Revilla" <er...@si...>
Cc: "modeling-users" <mod...@li...>
Sent: Sunday, February 29, 2004 2:37 PM
Subject: Re: [Modeling-users] Another question about sessions and =
EditingContexts (sorry)



"Ernesto Revilla" <er...@si...> wrote:
> Dear all,
>=20
> as stated in the documentation, section 6. Integration in an =
application,
> using an application server, actually it is recomended to use a fresh
> EditingContext for each session. But it states also, that changes made
> permanent with saveChanges will not be visible to other =
EditingContexts. Is
> the also the case for Zope ZEditingContextSessioning? Could anybody =
tell me
> in which environment she/he uses modeling, and how he treats the
> EditingContexts? (I'm looking for application server like uses.)

  This is the case in every multi-ECs environment, including Zope and
  ZECSessioning.

I currently have the intention of solving that longstanding issue of
synchronizing ECs --and this is a prerequisite for optimistic
locking. Would you have some time testing patches on that topic?

-- S=E9bastien.

Re: [Modeling-users] Another question about sessions and EditingContexts (sorry)

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

"Ernesto Revilla" <er...@si...> wrote:
> Dear all,
>=20
> as stated in the documentation, section 6. Integration in an application,
> using an application server, actually it is recomended to use a fresh
> EditingContext for each session. But it states also, that changes made
> permanent with saveChanges will not be visible to other EditingContexts. =
Is
> the also the case for Zope ZEditingContextSessioning? Could anybody tell =
me
> in which environment she/he uses modeling, and how he treats the
> EditingContexts? (I'm looking for application server like uses.)

  This is the case in every multi-ECs environment, including Zope and
  ZECSessioning.

I currently have the intention of solving that longstanding issue of
synchronizing ECs --and this is a prerequisite for optimistic
locking. Would you have some time testing patches on that topic?

-- S=E9bastien.

Re: [Modeling-users] Some more questions

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

"Ernesto Revilla" <er...@si...> wrote:
> Dear all,
>=20
> * how do I query for DateTime fields?

Example:

    ec.fetch('Writer', 'birthday =3D=3D "1939-10-27 08:31:15"')
or
    ec.fetch('Writer', 'birthday like "1939-10-27*"')

> * modeling validates mx.DateTime.DateTime and mx.DateTime.Date objects, b=
ut
> not mx.DateTime.Time. (efectively DateTimeDelta). Is it possible to handle
> these?

Yes it is: try the attached patch!

-- S=E9bastien.


------------------------------------------------------------------------
diff -u -r1.21 Attribute.py
--- Attribute.py        22 Feb 2004 17:31:37 -0000      1.21
+++ Attribute.py        29 Feb 2004 13:10:39 -0000
@@ -56,7 +56,7 @@
 # python
 import types, string, sys, time
 from cgi import escape
-from mx.DateTime import DateTime, DateFrom
+from mx.DateTime import DateTime, DateFrom, Time
=20
 # Module constants
 # useless, should be dropped
@@ -76,7 +76,7 @@
=20
 def date_types():
   "Returns the set of valid date types"
-  avail_types=3D[ type(DateTime(0)) ]
+  avail_types=3D[ type(DateTime(0)), type(Time(0)) ]
   try:
     import DCOracle2
     avail_types.append(type(DCOracle2.Date(0,0,0)))
------------------------------------------------------------------------

Re: [Modeling-users] leaving the database open

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

  Hi and sorry for the delay in the answer,

"Ernesto Revilla" <er...@si...> wrote:
> Hi all,
>=20
> strange thing (for me) that the AdaptorContext does not define a close
> operation.
>=20
> Working with SQLite, I only see code to close the database when all chann=
els
> are closed and the os.environ.get('MDL_TRANSIENT_DB_CONNECTION') is set (=
to
> something different as '' and 0).

You're right: the connection to the db is only closed in this situation.
So, if you need to close it after an operation, you have to set
MDL_TRANSIENT_DB_CONNECTION to true before that operation.

  The mechanism will probably change however in the near future; maybe a
  delegate can handle those situations.

  Now if you need a method to close the database connection after some
operations took place, this can be made the way it is in
AbstractDBAPI2AdaptorContext.adaptorChannelDidClose() -- the important
thing is to set self._cnx to None so that it automatically reconnects
when needed. If you're doing this in a multi-thread environment with
many ECs, you should lock the ObjectStoreCoordinator (which is any EC's
rootObjectStore()) before closing the connection.


> The problem arose when I executed the mdl_create_DB_schema.py with
> execfile from within my PyModel definition with execfile with the -R
> option. The database was open (after running a schema creation). So
> rerunning the script with some changes in the model, didn't drop the
> DB.
>=20
> So I have the following questions:
> * does loading the model open the database?

Not at all --if you want to see when the db connection is opened you can
MDL_ENABLE_DATABASE_LOGGING to "yes".

> * is it possible to close explicitly the database, i.e. context, so
> that after the creation of the schema the database is closed?

I'll suggest setting MDL_TRANSIENT_DB_CONNECTION

> * what does the MDL_TRANSIENT_DB_CONNECTION mean:
>   a) do not close the DB when all cursor have closed, or
>   b) the opposite, close the DB when all channels are closed?

If set to true, it closes the db when the last opened channel is
closed. The default behaviour is now to keep the db connection
opened. BTW I've just realized that the User's Guide says exactly the
opposite, this should be fixed.

>=20
> If mdl_generate_DB_schema.py is invoked with the -R option, using
> SQLiteAptor, and the file does not exist, an error is rosen. Perhaps this
> could be ignored. (-R is: drop the database if it exists). This could be
> done with the following code in
> dropDatabaseWithAdministrativeConnectionDictionary:
>=20
>     try:
>       os.unlink(administrativeConnectionDictionary['database'])
>     except OSError, exc:
>       # ignore if file does not exist, else, reraise exception
>       if not exc.errno=3D=3D2:
>         raise


Well, the error shouldn't be ignored when the file does not exist to be
consistent with other adaptors which also raise when an attempt is made
to drop an non-existing database.

In the script, -R is: drop the db and recreate it and agreed, it fails
if the database does not exist; if you want to ignore the error, the
option -i/--ignore-errors is your friend :)  Now if you want to
explictly ask for DB creation (not re-creation), then you want to use
-C.

  I'm not sure I fully understood your use-case with executing the
  script, hopefully this answers your question.

-- S=E9bastien.

Re: [Modeling-users] Licence issues

[Federico H. <fh...@vi...>]

On Wed, 2004-02-25 at 10:51, Yannick Gingras wrote:
> If that matter, my vote it to keep it GPL, it deserve it.

I'm with Yannick!

	Fede

--=20
GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key BD02C6E0
Key Fingerprint: 04F4 08C5 14B7 2C3D DB21  ACF8 6CF5 0B0C BD02 C6E0

[Modeling-users] Another question about sessions and EditingContexts (sorry)

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

Dear all,

as stated in the documentation, section 6. Integration in an =
application, using an application server, actually it is recomended to =
use a fresh EditingContext for each session. But it states also, that =
changes made permanent with saveChanges will not be visible to other =
EditingContexts. Is the also the case for Zope =
ZEditingContextSessioning? Could anybody tell me in which environment =
she/he uses modeling, and how he treats the EditingContexts? (I'm =
looking for application server like uses.)

Best regards, Erny

[Modeling-users] Some more questions

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

Dear all,

* how do I query for DateTime fields?
* modeling validates mx.DateTime.DateTime and mx.DateTime.Date objects, =
but not mx.DateTime.Time. (efectively DateTimeDelta). Is it possible to =
handle these?

Best regards, Erny

[Modeling-users] leaving the database open

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

Hi all,

strange thing (for me) that the AdaptorContext does not define a close =
operation.

Working with SQLite, I only see code to close the database when all =
channels are closed and the =
os.environ.get('MDL_TRANSIENT_DB_CONNECTION') is set (to something =
different as '' and 0).

The problem arose when I executed the mdl_create_DB_schema.py with =
execfile from within my PyModel definition with execfile with the -R =
option. The database was open (after running a schema creation). So =
rerunning the script with some changes in the model, didn't drop the DB.

So I have the following questions:
* does loading the model open the database?
* is it possible to close explicitly the database, i.e. context, so that =
after the creation of the schema the database is closed?
* what does the MDL_TRANSIENT_DB_CONNECTION mean:
  a) do not close the DB when all cursor have closed, or
  b) the opposite, close the DB when all channels are closed?

If mdl_generate_DB_schema.py is invoked with the -R option, using =
SQLiteAptor, and the file does not exist, an error is rosen. Perhaps =
this could be ignored. (-R is: drop the database if it exists). This =
could be done with the following code in =
dropDatabaseWithAdministrativeConnectionDictionary:

    try:
      os.unlink(administrativeConnectionDictionary['database'])
    except OSError, exc:
      # ignore if file does not exist, else, reraise exception
      if not exc.errno=3D=3D2:
        raise

with best regards, Erny

Re: [Modeling-users] Newbie question =)

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

Sebastien Bigaret <sbi...@us...> wrote:
> Well, I would advise you not to change anything in the validation logic.
> Even if nothing prevents you from doing this, there isn't much situation
> which requires modification of the objects graph in validation methods.
> To put it differently, i'd say that the validation logic is here to
> prevent any bug or unhandled situations to be able to corrupt objects /
> database invariants in any ways (just an advice, really, nothing in the
> framework would prevent you to change objects during the validation
> process)

However, in most cases you just cannot decide what to do if the
validation fails: suppose your validation logic fails because a person
has two default bank account, what should be done then? Randomly choose
one of them to be the default? Sounds awkward as well, doesnt it :))

-- S=E9bastien.

Re: [Modeling-users] Newbie question =)

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

        Hi,

Tom Hallman <hal...@dm...> wrote:
> Hi all,
>=20
>    Here's a situation I have, and I'm trying to figure out how best to do=
 it
> using Modeling.
>=20
>    I have a Person entity, and it has a ToMany relationship with BankAcco=
unt
> entities. One of the attributes of BankAccount is "isDefault", which is 1=
 if
> the particular account is (duh) the default one, and 0 otherwise.
>=20
>    So part of the validation logic for validateIsDefault(), I figure, sho=
uld
> make all other BankAccounts' isDefaults set to 0 if this new account is s=
et to
> 1.

Well, I would advise you not to change anything in the validation logic.
Even if nothing prevents you from doing this, there isn't much situation
which requires modification of the objects graph in validation methods.
To put it differently, i'd say that the validation logic is here to
prevent any bug or unhandled situations to be able to corrupt objects /
database invariants in any ways (just an advice, really, nothing in the
framework would prevent you to change objects during the validation
process)

  In your case, I would rather:

- make a to-one relationship from Person to BankAcct,=20
  named defaultBankAcct, with no inverse. This way, you have a dedicated
  getter and setter for the default bank account.

- If you need to know if a BankAcct is a default, then add something
  like this to BankAcct:

    def isDefault(self):
      return self is self.getPerson().getDefaultBankAcct()

  (I'm here assuming that a BankAcct always have a related Person, which
  is probably the case)

- Add the following validation method to Person:

    def validateDefaultBankAcct(self, value):
      if not self.value or self.value not in self.bankAccounts():
        raise Validation.ValidationException

  assuming here that you want to make sure that a default bank account
  is always defined (*) --in addition to making sure that a default bank
  acct is one of the person's; of course, you can additionally make sure
  that the default bank account is part of the registered bank accounts
  of a person in the setter setDefaultBankAcct().

  (*) this also implies that a Person has at least one bank acct, btw.


I'll finally add that this is just a proposal, not the only way to do
it. You could have very good reasons to make it your way --for example,
if you have to use an already existing database. In this case, I'd
suggest however to keep the same API, with class Person controlling its
default bank acct; or alternatively to make BankAcct.setDefault() reset
the other getPerson().getBankAccts() --even if as for me, this option
seems really awkward :)

>    The problem is that I'd like to get at the editing context which is ca=
lling
> validateIsDefault in the first place, so that changing the other isDefaul=
ts to
> 0 would *only* happen if the entire new account gets correctly saved. (In
> other words, the ec I create in this function, I think, should be a neste=
d ec
> of the calling ec.)
>=20
>    Is there a way to do this? Or am I going about this in the wrong way?

I'm not sure I fully understand your question here, so, to make it
clear:

- if you're only concerned by the data consistency, ie that a newly
  created bank account, made the default one, cannot be saved in
  database while other changes in the EC are saved, you only need one
  EC: when an EditingContext savesChanges(), *all* changes are saved, or
  *none* are saved.

- if you want to be able to cancel the process of:
    - getting new properties for a new bank account,
    - creating a new bank account with these properties,
    - assigning it to a person,
    - make it the default bank account,
=20=20
  at any point, without having to remember (in the code) whether you
  already created the bank acct (in which case you need to delete() it),
  or if it was already assigned to the person as the default (in which
  case you need to restore the old default, hence you'll have to store
  it before changing it), etc., well, if you do not want that, then yes!
  an child EditingContext is your friend:

    - create it,

    - use it to create the new bank acct, etc.

    - when finished, saveChanges(), then do not forget to saveChanges()
      on its parent as well (the first one save the changes to the
      parent, the second, to the database), OR simply delete it to
      discard any changes made in the child EC.


  Hope this helps!

-- S=E9bastien.

Re: [Modeling-users] Some more corrections to the documentation (manual) and some questios

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

        Hi ,

"Ernesto Revilla" <er...@si...> wrote:
> Question: in secion 2.4.8 Association, in the 'Important' part it says:
> Association objects always define a to-one association from the first ent=
ity to the second entity, and an inverse to-many relationship from the seco=
nd entity to the first one.
>=20
> Is this true, although the multiplicity has no be defined as:
>               multiplicity=3D[ [0, 1], [0, None] ],
> like
>               multiplicity=3D[ [0, None], [0, 1] ],
>=20
> ?

Yes, this is true, if you try to inverse toOne/toMany multiplicities
you'll get a "ValueError: invalid multiplicity dst->src: should be
toMany"

>=20
> If the foreign key value must not be null, e.g. like the 'customer' field=
 . for invoices, orders, etc., the multiplicity would be:              [1, =
1], [0, None]
> as in:
>     Association('Invoice', 'Customer', relations=3D['customer','invoices'=
],
>                 multiplicity=3D[ [1, 1] , [0, None] ],
>                 delete=3D['nullify','deny'])
> ??

Right: a lower bound=3D=3D1 requires any invoice to have exactly one custom=
er.

> Generation of DB-Schema with mdl_generate_DB_schema.py:
> When I do:
>     python p:mdl_generate_DB_schema.py -c -v -C modelo.py
>=20
> I get:
>     Error: option -C requires --admin-connection-dict
> 1.) I don't access the DB (-c option) so a admin dictionary should not be=
 needed.
> 2.) there is no --admin-connection-dict parameter, only a --admin-dsn par=
ameter

  You're absolutely right --for both the typo. and the fact that we
should probably just issue a warning if -c is set while --admin-dsn
would be required without -c.


  And thank you for the doc. corrections and the enhancement proposal.
  I'll look at them closely this week-end and integrate the corrections
  then. Thanks again.

-- S=E9bastien.

[Modeling-users] Newbie question =)

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

Hi all,

   Here's a situation I have, and I'm trying to figure out how best to do it 
using Modeling.

   I have a Person entity, and it has a ToMany relationship with BankAccount 
entities. One of the attributes of BankAccount is "isDefault", which is 1 if 
the particular account is (duh) the default one, and 0 otherwise.

   So part of the validation logic for validateIsDefault(), I figure, should 
make all other BankAccounts' isDefaults set to 0 if this new account is set 
to 1.

   The problem is that I'd like to get at the editing context which is 
calling validateIsDefault in the first place, so that changing the other 
isDefaults to 0 would *only* happen if the entire new account gets correctly 
saved. (In other words, the ec I create in this function, I think, should be 
a nested ec of the calling ec.)

   Is there a way to do this? Or am I going about this in the wrong way?

   Thanks 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] Licence issues

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

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

On February 24, 2004 10:42, Marcos Dione wrote:
>     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 think that the dual licencing (=E0 la Qt) is better than the LGPL if
you want something back from your code.  With dual licencing, you
either get an application back or at least some money.  With the LGPL,
someone user your lib on a commercial product and you don't get
anything back.

Given two comparable libraries, I will alway tend to support the one
that enforce the free software spirit the most (GPL > LGPL > BSD).  If
Cygnus can make money with GPL code, why can't you too ?  How would
closing your sources help you ?  If you go the GPL way, yes, you have
your source open but you can use much more code that you won't have to
develop in-house.  Your application will cost you less to develop.

  http://www.gnu.org/licenses/why-not-lgpl.html

Modelling is that kind of framework that is clever enough for you to say
that you prefer to open your sources and use Modelling instead of
closing your source and code it from scratch.

If that matter, my vote it to keep it GPL, it deserve it.

=2D --=20
Yannick Gingras                              "The best writing is rewriting=
=2E"
Coder for OBB : Overhead Brownish-orange Bivouac        -- Elwyn Brooks Whi=
te
http://OpenBeatBox.org

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

iD8DBQFAPKheZJ8/OobqizMRAlmKAKCu6QvKvQN02E4aMknmCif87CYTlACcDWIT
ZXy+sOQMnqq3DP5R4glPUS0=3D
=3DdJj+
=2D----END PGP SIGNATURE-----

[Modeling-users] Some more corrections to the documentation (manual) and some questios

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

Hi,

in section  2.4.7.3 RToMany, it says:
RToOne objects describe a to-many relationship ... should be RToMany

in section 2.4.8 Association : incorrect spelling: shortvut should be =
shortcut

in section 2.6.3.2 A short example:=20
Now that we now.... should read Now that we know...


Question: in secion 2.4.8 Association, in the 'Important' part it says:
Association objects always define a to-one association from the first =
entity to the second entity, and an inverse to-many relationship from =
the second entity to the first one.

Is this true, although the multiplicity has no be defined as:
              multiplicity=3D[ [0, 1], [0, None] ],
like
              multiplicity=3D[ [0, None], [0, 1] ],

?

If the foreign key value must not be null, e.g. like the 'customer' =
field . for invoices, orders, etc., the multiplicity would be:           =
   [1, 1], [0, None]
as in:
    Association('Invoice', 'Customer', =
relations=3D['customer','invoices'],
                multiplicity=3D[ [1, 1] , [0, None] ],
                delete=3D['nullify','deny'])
??

Generation of DB-Schema with mdl_generate_DB_schema.py:
When I do:
    python p:mdl_generate_DB_schema.py -c -v -C modelo.py

I get:
    Error: option -C requires --admin-connection-dict
1.) I don't access the DB (-c option) so a admin dictionary should not =
be needed.
2.) there is no --admin-connection-dict parameter, only a --admin-dsn =
parameter


Best regards, Erny