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

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

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

        Hi,

Marcos Dione <md...@vi...> wrote:
>=20
>     hi all. I'm experimenting since a few months w/ building a rollback
> scheme above modeling. the problems I found were this:
>=20
>     given a EditingContext, there a re two kind of objects registered at
> the moment fo saveChanges(): from-database ones (globalID() is an
> instance of KeyGlobalID), and new ones (globalID() is an instance of
> TemporaryGlobalID). when I roll back, I do the following:
>=20
> * 'hold' the model: any from-database object gets hold by means of
> snapshot_raw(). new ones are simply forgoten.
>=20
> * build a new EditingContext.
>=20
> * repopulate it with the old objects. from-database ones get reinserted
> via faultForRaw(), and new ones simply requesting a new instance of the
> proper class.

Could you be a little more explicit about the use cases behind this
rollback mechanism? Are "from-db objects" changed within the EC? Or do
you simply want to remove the inserted ones, and to revert the
persistent ones to the state they have in the db? Or...?

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

(just asking all this to learn a bit more about your context)

>=20
>     this works fine, but a probblem arises: if I create a new object,
> add it to the EditingContext(), then saveChenges(), it *sometimes* gets
> converted to a from-database one (which is what I would mostly spect;
> see definition above) and sometimes it doesn't (which would not be so
> bad if it wouldn't be just 'sometimes'). keep in mind that now I'm just
> playing with only one entity, so it doesn't seem to be an entity
> problem, if you know what I mean.
>=20
>     is this possible (the sometimes part), could it be a bug in
> Modeling, or I'm just getting lucky sometimes? which would be the
> spected behaviour? if you need some code I can post it tomorrow.


I really need some code here, I'm not positively sure to see what the
problem is. What I understand follows.

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

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


-- S=E9bastien.

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

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

User-Agent: Mutt/1.3.28i


    hi all. I'm experimenting since a few months w/ building a rollback
scheme above modeling. the problems I found were this:

    given a EditingContext, there a re two kind of objects registered at
the moment fo saveChanges(): from-database ones (globalID() is an
instance of KeyGlobalID), and new ones (globalID() is an instance of
TemporaryGlobalID). when I roll back, I do the following:

* 'hold' the model: any from-database object gets hold by means of
snapshot_raw(). new ones are simply forgoten.

* build a new EditingContext.

* repopulate it with the old objects. from-database ones get reinserted
via faultForRaw(), and new ones simply requesting a new instance of the
proper class.

    this works fine, but a probblem arises: if I create a new object,
add it to the EditingContext(), then saveChenges(), it *sometimes* gets
converted to a from-database one (which is what I would mostly spect;
see definition above) and sometimes it doesn't (which would not be so
bad if it wouldn't be just 'sometimes'). keep in mind that now I'm just
playing with only one entity, so it doesn't seem to be an entity
problem, if you know what I mean.

    is this possible (the sometimes part), could it be a bug in
Modeling, or I'm just getting lucky sometimes? which would be the
spected behaviour? if you need some code I can post it tomorrow.

    TIA.

Re: [Modeling-users] dynamic metaclass overwrites custom methods

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

On 02 Sep 2004 20:42:44 +0200
Sebastien Bigaret <sbi...@us...> wrote:

 
> That should be handled, you're absolutely right.  However, I would
> suggest to make a 'warning' instead, and to overwrite the already
> defined method m() with a new one calling simply self.willChange()
> before calling m() --and the same for getAttribute()() but w/
> self.willRead() instead.

Letting the framework call willChange/willRead *before* calling my 
biz logic sounds elegant but takes the freedom to define if/when to call
them away, plus I like not to write code that addresses "_AttrName" internal
attributes directly and prefer to let the framework generated methods do it.
On top of that it makes code generation a little bit more complex for no
clear (? to me ?) advantage, I'd stick to the simple solution :)
what do you think?

--
Delio

Re: [Modeling-users] How the transactions are done in the saveChanges?

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

        Hi,

  Since this discussion was pending for a while, I leave here almost the
  whole the context

Marco Bizzarri <m.b...@ic...> wrote:
> Sebastien Bigaret wrote:
> |         Hi,
> |
> | To all: I'll probably be off for a day or two from now, so
> | do not expect me to answer quickly in this period ;)
>=20
> No problem :)
>=20
> | Marco Bizzarri wrote:
> |
> |>Pfeeww... I didn't expect such a looong answer... :)
> |
> |
> | This will be very short one, before a more complete in the coming days.
> | I just want to correct something quickly:
> |
> | [...]
> |
> |>In a web environment, like Zope or whatever, you've a clear
> |>distinction of a transaction: the arrive of a request, the
> |>sending of response. All inside these two events can be
> |>considered a transaction; at least, this is what the user can
> |>perceive as a transaction.
> |
> | [...]
> |
> |>| Back on this, just a few words: having a single
> |>BEGIN/COMMIT or ABORT
> |>| per zope transaction means that you want to restrict what the
> |>| framework is able to do. Updates in an EC can take more
> |>than one zope
> |>| transaction to be achieved, for example if they are saved after
> |>| several html pages have been served one after the other (think of a
> |>| wizard, at the end of which you confirm or cancel the changes).
> |>
> |>I don't think this is possible in the current integration of
> |>MDL and Zope.
> |>
> |>IIRC, MDL register itself with the _finish method...
> |>
> |>~  def _finish(self):
> |>~    self.ec.lock()
> |>~    self.ec.saveChanges()
> |>~    self.ec.unlock()
> |>
> |>Now, this means that, at the end of *each* Zope transaction
> |>you will do a saveChanges on your ec. Therefore, if you
> |>update your objects inside the page of the wizard, they will
> |>be stored on the RDB.
> |
> |
> |
> | No, a session's EC is NOT bound by default to the zope TM,
> | (even if the _finish() method is used when it is bound to it)
> | cf. section 6.4. & 6.4.1 in the User's Guide.  If you observed
> | the oppposite this is definitely a bug that should be fixed.
>=20
> No, I was assuming the bind_saveChanges_to_zope_transactions behaviour.

Okay, fine.

> | So, basically, you should get exactly what you describe:
> |
> |>The above behaviour could be configurable. You could have an
> |>"auto-commit" EC and a "non-auto-commit" EC (i.e. different
> |>subclasses), and let the developer choose according to its need.
> |
> |
> | based on the ZEditingContextSessioning's property
> | 'bind_saveChanges_to_zope_transactions'. It IS possible to
> | decorrelate EC.saveChanges() and the zope TM, it should even
> | be the default (or, I repeat, this is definitely a bug).
> |
> | [...]
> |
> |>Also, even though you could in principle do some
> |>saveChanges() by yourself, this would be looking for havoc.
> |>Indeed, Zope relies on the fact that a transaction can be
> |>redone from the start, if something goes wrong.
> |
> |
> | Zope does not insist to rely on this if you insist of ignoring
> | its TM ;)
>=20
> I disagree.
>=20
> Zope itself uses a conflict resolution approach, where, aside from
> interactions with the RDB, you can have ConflictErrors, which are
> raised, catched by the ZPublisher which redo the transaction from the
> beginning.
>=20
> | Seriously, it's possible to build a whole application on this principle.
>=20
> [...]
>=20
> This is a point which is very interesting to me. However, I think you
> could be very limited on what you can use inside Zope... ZCatalogs, for
> example, should be exluded, because they can easily generate
> ReadConflictError.
>=20
> However, I suspect you have much more experience on this topic than me,
> and I would appreciate your point of view.

  Well, AFAIK (Read)ConflictErrors are handled within each storage and
  do not interfere with others --unless that, after the transaction has
  been retried n times, it is abandoned and makes the whole transaction
  fail.

However I can be wrong on this point and have no time to double-check
what I say, so if you have informations suggesting or proving the
contrary I'd be happy to hear from you.


  What I was saying with:

> | Zope does not insist to rely on this if you insist of ignoring
> | its TM ;)

  is that you can build a whole application without binding the DB txns
  (ec.saveChanges()) to zope txns  --and in fact that's exactly what I
  do.  This mean, in particular, that I never worked w/ applications
  where ec.saveChanges() are bound to the zope txn machinery, so I
  cannot be absolutely positive about what I'm saying above.

But some documents, such as TM.py or:
http://www.zope.org/Members/petrilli/WritingADA


  Now, I must double-check the design in ZECSessioning, I think I've
  just see a flaw in it: it should probably implement method tpc_vote()
  calling self.ec.validateChanges(), before any txns is actually
  committed.  Any comment, anyone?


> |>I think I should review a little... consider an application
> |>where you have a large number of users, 1000, perhaps, each
> |>having its own ec... should we notify each user of the changes?
> |
> |
> | Wow, I only meant notifying the ECs, not the users ;) unless you decide
> | so, obviously.
> |
> [...]
>=20
> Of course, my wording was not that good. If I have 1000 users active, I
> have 1000 sessions, with 1000 EC. I could have to notify to 999 EC when
> one makes a change... or not?

  Yes, you do have to --if you don't, then you can get inconsistencies.
  Of course, the notification process is quite fast, and the appropriate
  methods (solving inconsistencies) are only triggered when needed.


> |   Hopefully this succeeds some of my points in the previsou email a
> |   little clearer. Again, yes, this would be a lot clearer with a >
> |   tutorial, a zope dedicated section and a sample toy application...
>=20
> I would be happy to contribute something on this point...

Great :)

-- S=E9bastien.

Re: [Modeling-users] pymodel and association multiplicity

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

The patch has been integrated into the CVS main trunk and will be in the
next release.  Thanks for reporting!

-- S=E9bastien.


Ref.: Bug item #1023234
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1023234&group=
_id=3D58935&atid=3D489335



no...@ti... wrote:
> Hello,
>=20
> I found what may be a bug in pymodel association multiplicity validation:
>=20
> if I try:
> 	multiplicity=3D[ [ 0, 1 ], [ 0, 2 ] ],
> with vanilla Modeling 0.9-pre-17.1 it fails to accept it as a valid assoc=
iation.
>=20
> patch follows, if I'm correct I'll post it in the patches section :)
>=20
> --
> Delio
>=20
> diff -aur ModelingCore-0.9-pre-17.1/Modeling/PyModel.py Modeling/PyModel.=
py
> --- ModelingCore-0.9-pre-17.1/Modeling/PyModel.py       2004-02-15 07:27:=
03.000000000 +1300
> +++ Modeling/PyModel.py        2004-08-14 15:27:18.000000000 +1200
> @@ -854,7 +854,7 @@
>      ds_mult=3Dself.multiplicity[1]
>      if sd_mult[1]>1:
>        raise ValueError, 'invalid multiplicity src->dst: should be toOne'
> -    if not (ds_mult[1] in (None, '*', -1) or ds_mult[0]>1):
> +    if not (ds_mult[1] in (None, '*', -1) or ds_mult[1]>1):
>        raise ValueError, 'invalid multiplicity dst->src: should be toMany'
>      return sd_mult, ds_mult

Re: [Modeling-users] Re: patch for quoted entities, attributes

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

        Hi John,

John Lenton <jl...@gm...> wrote:
> S=E9bastien,
>=20
> I know this might be imposing too much, but could you possibly tell me
> what I could to this patch to make it accepted into Modeling?

Sorry, this slipped out out my mind; and worse, the post itself was left
unanswered as far as I can see in the archives. Okay, so, first: I have
no problem with the feature itself. Second, the problems you list (the
tests not being updated yet, etc.)  should definitely be addressed
before it's integrated.

  And now for a slightly OT discussion: I'm sorry for any inconvenience
  that the delay in answering the request has caused. In fact and as you
  probably noticed, I've really had problems addressing issues in a
  reasonable time those last months, there's a lot of pending bugs,
  patches waiting for approval or further discussion, etc. Not to speak
  about the 0.9 release candidate waiting, obvisoulsy.  Well, this is
  all done on my spare time, which is not that big those days...  What I
  can say is that I'm currently considering reorganizing things so that
  at least pending requests do not wait too long --more to come in the
  coming weeks.

Back on your specific request, what would accelerate the integration in
the framework would be, definitely, to address the issues listed in your
original post (tests, making this work for the other adaptors).

  On the feature itself, I think I'd prefer not to make it the default,
  but controlled by setting the appropriate variable, and probably
  adding an env. variable for triggering it. What do you think?  Can you
  also comment on your change on Entioty.externalNameForInternalName()
  where the default for useAllCaps is changed from '1' to '0' ?


Oh, and last: it would help a lot (at least, for me not to forget about
it!) if you could add an entry for this in the patch section.


-- S=E9bastien.

[Modeling-users] Re: patch for quoted entities, attributes

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

S=E9bastien,

I know this might be imposing too much, but could you possibly tell me
what I could to this patch to make it accepted into Modeling?

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

Re: [Modeling-users] dynamic metaclass overwrites custom methods

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

        Hi,

no...@ti... wrote:
> Hello,
>=20
> if I define:
>=20
> class A:
>     __metaclass__ =3D dynamic.CustomObjectMeta
>     entityName =3D 'A'
>     mdl_define_properties =3D 1
>=20
>     def setName( self, value ):
> 	pass
>=20
> name being a class property, when the metaclass __new__ method populates
> the instance with code it overrides setName with the stock one.
> My fix here is to check for the existence of the method before overriding
> and rename it to 'mdl_'+method_name (which might not be inline
> with your naming conventions) in case it's already there.
>=20
> patch follows
>=20
> comments anyone?

That should be handled, you're absolutely right.  However, I would
suggest to make a 'warning' instead, and to overwrite the already
defined method m() with a new one calling simply self.willChange()
before calling m() --and the same for getAttribute()() but w/
self.willRead() instead.

  What do you think?

-- S=E9bastien.


PS: for Ernesto: I did not forget about your post on properties, I just
    did not take the time to get back on it yet, sorry.


>=20
> cheers
> --
> Delio
>=20
> diff -aur /home/delio/tmp/ModelingCore-0.9-pre-17.1/Modeling/dynamic.py .=
/dynamic.py
> --- /home/delio/tmp/ModelingCore-0.9-pre-17.1/Modeling/dynamic.py       2=
004-02-17 09:01:06.000000000 +1300
> +++ ./dynamic.py        2004-08-31 19:51:40.000000000 +1200
> @@ -265,6 +265,9 @@
>    func_name, c=3Dgetter_code(prop)
>    info(classdict, "adding getter: %s"%func_name)
>    getter=3Dfunction_for_code(c, func_name)
> +  if classdict.has_key( func_name ):
> +    func_name =3D 'mdl_' + func_name
> +    info(classdict, "getter already defined renaming to: %s"%func_name)
>    classdict[func_name]=3Dgetter
>=20=20
>  def define_getters(entity, classname, classdict):
> @@ -277,6 +280,9 @@
>    for func_name, c in names_and_funcs:
>      info(classdict, "adding setter: %s"%func_name)
>      setter=3Dfunction_for_code(c, func_name)
> +    if classdict.has_key( func_name ):
> +        func_name =3D 'mdl_' + func_name
> +        info(classdict, "setter already defined renaming to: %s"%func_na=
me)
>      classdict[func_name]=3Dsetter
>=20=20
>  def define_setters(entity, classname, classdict):

Re: [Modeling-users] pymodel and association multiplicity

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

no...@ti... wrote:
> Hello,
>=20
> I found what may be a bug in pymodel association multiplicity validation:
>=20
> if I try:
> 	multiplicity=3D[ [ 0, 1 ], [ 0, 2 ] ],
> with vanilla Modeling 0.9-pre-17.1 it fails to accept it as a valid assoc=
iation.
>=20
> patch follows, if I'm correct I'll post it in the patches section :)

Right, thanks for reporting.  I'd prefer a report in the 'Bugs' section
w/ the patch attached, since this is not an enhancement but definitely a
bug fix!

-- S=E9bastien.


>=20
> --
> Delio
>=20
> diff -aur ModelingCore-0.9-pre-17.1/Modeling/PyModel.py Modeling/PyModel.=
py
>--- ModelingCore-0.9-pre-17.1/Modeling/PyModel.py       2004-02-15 07:27:0=
3.000000000 +1300
>+++ Modeling/PyModel.py        2004-08-14 15:27:18.000000000 +1200
>@@ -854,7 +854,7 @@
>     ds_mult=3Dself.multiplicity[1]
>     if sd_mult[1]>1:
>       raise ValueError, 'invalid multiplicity src->dst: should be toOne'
>-    if not (ds_mult[1] in (None, '*', -1) or ds_mult[0]>1):
>+    if not (ds_mult[1] in (None, '*', -1) or ds_mult[1]>1):
>       raise ValueError, 'invalid multiplicity dst->src: should be toMany'
>     return sd_mult, ds_mult

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

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

On Mon, 30 Aug 2004 22:55:37 +0200
Sebastien Bigaret <sbi...@us...> wrote:

> Ooops, two posts, only the last paragraphs that differ.
> The second one is the right one.  I removed the
> discussion of whether thsi is a YAGNI, just because I
> think that the consequences on the API and clarity of
> MDL statements are sufficient to discard the feature
> (unless it is proven that both approaches --more details
> or going the implict way) can be avoided.

Hello,

I'm back from the dead (sorta), unfortunately haven't had time to try
Sebastien's solution ( append login name to entities and modelname );
Tricky part is writing your biz ligic once:

class A:

    __metaclass__ = dynamic.CustomObjectMeta
    entityName = 'A'
    mdl_define_properties = 1

    def custom_method( self ):
	pass

and then have class A_login1, A_login2 generated on the fly,
playing with the entityName attribute, I'll give this a try later.

thanks for your feedback
--
Delio

[Modeling-users] pymodel and association multiplicity

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

Hello,

I found what may be a bug in pymodel association multiplicity validation:

if I try:
	multiplicity=[ [ 0, 1 ], [ 0, 2 ] ],
with vanilla Modeling 0.9-pre-17.1 it fails to accept it as a valid association.

patch follows, if I'm correct I'll post it in the patches section :)

--
Delio

diff -aur ModelingCore-0.9-pre-17.1/Modeling/PyModel.py Modeling/PyModel.py
--- ModelingCore-0.9-pre-17.1/Modeling/PyModel.py       2004-02-15 07:27:03.000000000 +1300
+++ Modeling/PyModel.py        2004-08-14 15:27:18.000000000 +1200
@@ -854,7 +854,7 @@
     ds_mult=self.multiplicity[1]
     if sd_mult[1]>1:
       raise ValueError, 'invalid multiplicity src->dst: should be toOne'
-    if not (ds_mult[1] in (None, '*', -1) or ds_mult[0]>1):
+    if not (ds_mult[1] in (None, '*', -1) or ds_mult[1]>1):
       raise ValueError, 'invalid multiplicity dst->src: should be toMany'
     return sd_mult, ds_mult

[Modeling-users] dynamic metaclass overwrites custom methods

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

Hello,

if I define:

class A:
    __metaclass__ = dynamic.CustomObjectMeta
    entityName = 'A'
    mdl_define_properties = 1

    def setName( self, value ):
	pass

name being a class property, when the metaclass __new__ method populates
the instance with code it overrides setName with the stock one.
My fix here is to check for the existence of the method before overriding
and rename it to 'mdl_'+method_name (which might not be inline
with your naming conventions) in case it's already there.

patch follows

comments anyone?

cheers
--
Delio

diff -aur /home/delio/tmp/ModelingCore-0.9-pre-17.1/Modeling/dynamic.py ./dynamic.py
--- /home/delio/tmp/ModelingCore-0.9-pre-17.1/Modeling/dynamic.py       2004-02-17 09:01:06.000000000 +1300
+++ ./dynamic.py        2004-08-31 19:51:40.000000000 +1200
@@ -265,6 +265,9 @@
   func_name, c=getter_code(prop)
   info(classdict, "adding getter: %s"%func_name)
   getter=function_for_code(c, func_name)
+  if classdict.has_key( func_name ):
+    func_name = 'mdl_' + func_name
+    info(classdict, "getter already defined renaming to: %s"%func_name)
   classdict[func_name]=getter
 
 def define_getters(entity, classname, classdict):
@@ -277,6 +280,9 @@
   for func_name, c in names_and_funcs:
     info(classdict, "adding setter: %s"%func_name)
     setter=function_for_code(c, func_name)
+    if classdict.has_key( func_name ):
+        func_name = 'mdl_' + func_name
+        info(classdict, "setter already defined renaming to: %s"%func_name)
     classdict[func_name]=setter
 
 def define_setters(entity, classname, classdict):

Re: [Modeling-users] toOne relationship returns base class instead of subcl

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

On 30 Aug 2004 23:09:40 +0200, Sebastien Bigaret
<sbi...@us...> wrote:
> 
> I'm currently working on the issue, I thought I could share my current
> thoughts.
> 
> So the problem w/ bug #1017127 is that the generated SQL is:
> >     SELECT DISTINCT t0.ID, t0.FK_PERSON
> >     FROM ADDRESS t0, PERSON t1
> >     WHERE ( PERSON.ID = 1 ) AND ( ADDRESS.FK_PERSON = PERSON.ID )
> 
> while it should take into account the class hierarchy, so that both
> PERSON and EMPLOYEE are traversed.
> 
> I was initially thinking of making as many SQL queries as there are
> pssible paths through the relationships (here, two: ADDRESS to PERSON,
> and ADDRESS to EMPLOYEE) --but then I remembered these could SQL queries
> could be UNIONed
> 
> So:
>     ec.fetch('Address', 'Person.id == 1')
> 
> should trigger the following query on the database [1]:
> 
>     SELECT DISTINCT t0.ID, t0.FK_PERSON
>       FROM ADDRESS t0
>           INNER JOIN EMPLOYEE t1 ON t0.FK_PERSON=t1.ID
>       WHERE t1.ID = 1
>     UNION
>     SELECT DISTINCT t0.ID, t0.FK_PERSON
>       FROM ADDRESS t0
>            INNER JOIN PERSON t1 ON t0.FK_PERSON=t1.ID
>       WHERE t1.ID = 1
> 
> NB: Incidentally, that UNION thing could also be a solution for the
>     current limitation of sort orderings that cannot be used w/ the
>     isDeep flag being set! Another story, though

yes, I was going to mention that in the other thread, but then I saw
that it involved modifying code all the way down to the database
adapter, and thought you'd be against it. Glad to know you aren't; you
do realize this will mean you need a second query to get at attributes
not present in the base class? Or would you select with the union of
all attributes, providing dummy values for those not present in each
table?

> Now the question is: suppose I have two plus two paths in the same fetch
> spec., such as in:
> 
>   AND:
>     ec.fetch('Address', 'person.id in [1,2,3] AND person.x.y like...')
> 
>   OR:
>     ec.fetch('Address', 'person.id in [1,2,3] OR person.x.y like...')
> 
> --> In the case of the 'AND' operator, do the two 'Person' refer to the
>     same table? In other words, do we get only two SELECTs union'ed?
> 
>     In the case of the 'OR' operator, do the two 'Person' refer
>     independant tables, either the same or different ones? In other
>     words, do we get 2*2=4 SELECTs union'ed?

if we were able to do sub-selects, we would (or could) write either as

    SELECT * FROM (SELECT * FROM Person UNION SELECT ... FROM Employee
) AS Person WHERE <qualifier>

(because that is what we mean, right?) and this reduces to

    SELECT * FROM Person WHERE <qualifier> UNION \
        SELECT ... FROM Employee WHERE <qualifier>
 
irrespective of <qualifier>.

> Is this what we want here, I fear I could miss something here?  Any
> comments will be appreciated!!

HTH---maybe it's me missing something, however; the "that is what we
mean" assumption is a strong one (in that it has big consquences).

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

Re: [Modeling-users] toOne relationship returns base class instead of subcl

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

I'm currently working on the issue, I thought I could share my current
thoughts.

So the problem w/ bug #1017127 is that the generated SQL is:
>     SELECT DISTINCT t0.ID, t0.FK_PERSON=20
>     FROM ADDRESS t0, PERSON t1
>     WHERE ( PERSON.ID =3D 1 ) AND ( ADDRESS.FK_PERSON =3D PERSON.ID )

while it should take into account the class hierarchy, so that both
PERSON and EMPLOYEE are traversed.

I was initially thinking of making as many SQL queries as there are
pssible paths through the relationships (here, two: ADDRESS to PERSON,
and ADDRESS to EMPLOYEE) --but then I remembered these could SQL queries
could be UNIONed

So:
    ec.fetch('Address', 'Person.id =3D=3D 1')

should trigger the following query on the database [1]:

    SELECT DISTINCT t0.ID, t0.FK_PERSON
      FROM ADDRESS t0
          INNER JOIN EMPLOYEE t1 ON t0.FK_PERSON=3Dt1.ID
      WHERE t1.ID =3D 1
    UNION
    SELECT DISTINCT t0.ID, t0.FK_PERSON
      FROM ADDRESS t0
           INNER JOIN PERSON t1 ON t0.FK_PERSON=3Dt1.ID
      WHERE t1.ID =3D 1


NB: Incidentally, that UNION thing could also be a solution for the
    current limitation of sort orderings that cannot be used w/ the
    isDeep flag being set! Another story, though


Now the question is: suppose I have two plus two paths in the same fetch
spec., such as in:

  AND:
    ec.fetch('Address', 'person.id in [1,2,3] AND person.x.y like...')

  OR:
    ec.fetch('Address', 'person.id in [1,2,3] OR person.x.y like...')

--> In the case of the 'AND' operator, do the two 'Person' refer to the
    same table? In other words, do we get only two SELECTs union'ed?

    In the case of the 'OR' operator, do the two 'Person' refer
    independant tables, either the same or different ones? In other
    words, do we get 2*2=3D4 SELECTs union'ed?=20=20=20
    NB:  2=3D=3Dlen([Person, Employee])

Is this what we want here, I fear I could miss something here?  Any
comments will be appreciated!!

-- S=E9bastien.



[1] w/ INNER JOINs or the equivalent WHERE clause if inner joins aint
    supported.

Sebastien Bigaret <sbi...@us...> writes:
> John Lenton <jl...@gm...> wrote:
> > On 29 Jul 2004 10:30:02 +0200, Sebastien Bigaret
> > <sbi...@us...> wrote:
> > >=20
> > >   Again, could you be a little more explicit, or exhibit a short
> > > example?  Sorry for getting back on this, but the only way I think th=
is
> > > can happen is the one I already posted (see below); if it's not the
> > > case, this is a serious bug I definitely do not want to let escape.
> >=20
> > sorry for the delay in answering, and the confusion when doing so. I
> > feel terribly embarrassed :(
>=20
>   Please don't feel embarrassed, that was worth waiting for it.
>=20
> > HOWever, here goes.
> >=20
> > With the attached model (which is ugly, and breaks some of your naming
> > conventions, but I just hacked out the attributes and renamed things
> > from the model being used by a team I'm helping to get up to speed),
> > using vainilla MDL 0.9-pre17.1 and NF 0.7:
> >=20
> >=20
> > >>> from Modeling.EditingContext import EditingContext
> > >>> import Store
> > >>> ec=3DEditingContext()
> > >>> ec.fetch('Address')[0]
> > <Address.Address object at 0x4071c74c>
> > >>> a =3D _
> > >>> p =3D ec.fetch('Person', isDeep=3D1)[0]
> > <Employee.Employee object at 0x4072d88c>
> > >>> p =3D _
> > >>> a.getPerson()
> > <Employee.Employee object at 0x4072d88c>
> > >>> a.getPerson().getId()
> > 1
> > >>> a.isFault()
> > False
> > >>> p.getAddress()
> > <Modeling.FaultHandler.AccessArrayFaultHandler instance at 0x40733a4c>
> > >>> list(p.getAddress())
> > [<Address.Address object at 0x4071c74c>]
> > >>> ec.fetch('Address', 'Person.id =3D=3D 1')
> > []
> > >>> ec.fetch('Address', 'Person.id =3D=3D 1', isDeep=3D1)
> > []
>=20
>   Wooo, I didn't even realize how serious this was.  The 'isDeep' flag
>   is unfortunately of no help here, because the problem is not with
>   Address and its underlying hierarchy (controlled by 'isDeep' flag) but
>   because of the generated SQL statement which  obviously doesn't take
>   into account the sub-entities for entity Person:
>=20
>     SELECT DISTINCT t0.ID, t0.FK_PERSON=20
>     FROM ADDRESS t0, PERSON t1
>     WHERE ( PERSON.ID =3D 1 ) AND ( ADDRESS.FK_PERSON =3D PERSON.ID )
>=20
> I've just submitted bug item #1017127 at
> https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1017127&gro=
up_id=3D58935&atid=3D489335,
> with your model and the corresponding code attached.
>=20
>   I'll search a definitive fix soon --my current thinking being about
>   the way that would allow even more complicated qualifiers to be
>   correctly handled as well, such as with: person.addresses.id in [2,3]
>   or w/ a qualifier traversing two or more relationships involving
>   entities with sub-entities.
>=20
>         Thanks a lot for the precise report,=20
>=20
> -- S=E9bastien.

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

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

Ooops, two posts, only the last paragraphs that differ.
The second one is the right one.  I removed the
discussion of whether thsi is a YAGNI, just because I
think that the consequences on the API and clarity of
MDL statements are sufficient to discard the feature
(unless it is proven that both approaches --more details
or going the implict way) can be avoided.

  Just to make it clear ;)

-- Sébastien.

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

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

Mario Ruggier <ma...@ru...> wrote:
[...]
>=20
> >   The real problem here is that you're gonna have objects corresponding
> >   different entities, all named Document but living in different
> >   database. Say you have database DB1 and DB2, you suggest that we can
> >   have at runtime objects doc1 and doc2, resp. being object for entities
> >   Document in DB1 and Document in DB2.
> >
> > Now you'll see the real problem if you realize that each object is
> > uniquely identified by its GlobalID.  And a GlobalID is the combination
> > od an entity name and its PK value(s).  If obj1 and obj2 and the same
> > PK, then they will get the same gID.
>=20
> But, is this simply a matter of changing the algorithm of how a GID is
> calculated?
> What if you throw in for example the database name as part of that=20
> calculation?
> Then, two objects may have the same entity name, same model name, same PK
> even... but if they come from a different db, there will not be any
> ambiguity... Note that this should also allow for the possibility to have
> the same object from the same database but in two distinct EditingContexts
> (not one that inherits from the other), to be correctly identified by the
> framework as the same object.

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

>=20
> > The consequences are, as expected,
> > devastative: snapshots are all mixed up, faults will pick up from the db
> > cache some data that in fact belongs to another database, etc...
> >
> >   In brief: your suggestion requires that the entities' names live in a
> >   separate namespace, or put differently, that an entity is identified =
by
> >   its name and its model's name.
>=20
> Yes, entities' names should be in a different namespace... but, I would go
> even further, and suggest also that models live in a separate namespace,
> defined by the database instance. Thus, you can instantiate the same model
> **exactly**, but bound to different databases.

Again, in this case, yes, this would work.  But this requires a lot of
changes.  And back to reality, I believe that:

1. Any app. that would require/benefit from such a feature can anyhow
   solve the problem differently and without much trouble,

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

        ec.fetch('Person')

   fuzzy about which Entity it fetches?=20

> [...] I want to understand better if the idea makes any sense, if
> having such a way of initialising an EC brings other advantages or
> disadvantages, and how difficult it is to modify the framework so
> drastically.
>=20
> I cannot appreciate how much work such a thing could be, but from what
> you say above I suspect it may be less than I thought ;)
>=20
> In any case, I think it would be too early to add this as a TODO item
> as yet, as further poking and contemplation is probably a good
> idea. Anyone else following this issue have an opinion?

You're right, that's way too early!...  As you probably already guessed,
the more I'm thinking about such an extension, the less I like it.  The
concepts is simple, but the consequences, esp. on the API, are not
desirable at all.  I believe that asking more than an Entity to be
supplied to e.g. ec.fetch() is not a very good idea, and I do not like
the idea of adding the level of implicit described above in statements
like ec.fetch().  Makes sense?

-- S=E9bastien.

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

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

Mario Ruggier <ma...@ru...> wrote:
[...]
>=20
> >   The real problem here is that you're gonna have objects corresponding
> >   different entities, all named Document but living in different
> >   database. Say you have database DB1 and DB2, you suggest that we can
> >   have at runtime objects doc1 and doc2, resp. being object for entities
> >   Document in DB1 and Document in DB2.
> >
> > Now you'll see the real problem if you realize that each object is
> > uniquely identified by its GlobalID.  And a GlobalID is the combination
> > od an entity name and its PK value(s).  If obj1 and obj2 and the same
> > PK, then they will get the same gID.
>=20
> But, is this simply a matter of changing the algorithm of how a GID is
> calculated?
> What if you throw in for example the database name as part of that=20
> calculation?
> Then, two objects may have the same entity name, same model name, same PK
> even... but if they come from a different db, there will not be any
> ambiguity... Note that this should also allow for the possibility to have
> the same object from the same database but in two distinct EditingContexts
> (not one that inherits from the other), to be correctly identified by the
> framework as the same object.

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

>=20
> > The consequences are, as expected,
> > devastative: snapshots are all mixed up, faults will pick up from the db
> > cache some data that in fact belongs to another database, etc...
> >
> >   In brief: your suggestion requires that the entities' names live in a
> >   separate namespace, or put differently, that an entity is identified =
by
> >   its name and its model's name.
>=20
> Yes, entities' names should be in a different namespace... but, I would go
> even further, and suggest also that models live in a separate namespace,
> defined by the database instance. Thus, you can instantiate the same model
> **exactly**, but bound to different databases.

Again, in this case, yes, this would work.  But this requires a lot of
changes.  And back to reality, I believe that:

1. Any app. that would require/benefit from such a feature can anyhow
   solve the problem differently and without much trouble,

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

        ec.fetch('Person')

   fuzzy about which Entity it fetches?=20

> [...] I want to understand better if the idea makes any sense, if
> having such a way of initialising an EC brings other advantages or
> disadvantages, and how difficult it is to modify the framework so
> drastically.
>=20
> I cannot appreciate how much work such a thing could be, but from what
> you say above I suspect it may be less than I thought ;)
>=20
> In any case, I think it would be too early to add this as a TODO item
> as yet, as further poking and contemplation is probably a good
> idea. Anyone else following this issue have an opinion?

You're right, that's way too early!...  As you probably already guessed,
the more I'm thinking about such an extension, the less I like it.  The
concepts is simple, but the consequences, esp. on the API, are not
desirable.  I believe that asking more than an Entity to be supplied to
e.g. ec.fetch() is not a very good idea, and I do not like the idea of
adding the level of implicit described above in statements like
ec.fetch().

  Plus, I now tend to believe that this is another YAGNI --the use-case
  that initited the discussion can be solved more elegantly (as ar as
  I'm concerned) by other means, as described in other posts.

-- S=E9bastien.

Re: [Modeling-users] toOne relationship returns base class instead of subcl

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

John Lenton <jl...@gm...> wrote:
> On 29 Jul 2004 10:30:02 +0200, Sebastien Bigaret
> <sbi...@us...> wrote:
> >=20
> >   Again, could you be a little more explicit, or exhibit a short
> > example?  Sorry for getting back on this, but the only way I think this
> > can happen is the one I already posted (see below); if it's not the
> > case, this is a serious bug I definitely do not want to let escape.
>=20
> sorry for the delay in answering, and the confusion when doing so. I
> feel terribly embarrassed :(

  Please don't feel embarrassed, that was worth waiting for it.

> HOWever, here goes.
>=20
> With the attached model (which is ugly, and breaks some of your naming
> conventions, but I just hacked out the attributes and renamed things
> from the model being used by a team I'm helping to get up to speed),
> using vainilla MDL 0.9-pre17.1 and NF 0.7:
>=20
>=20
> >>> from Modeling.EditingContext import EditingContext
> >>> import Store
> >>> ec=3DEditingContext()
> >>> ec.fetch('Address')[0]
> <Address.Address object at 0x4071c74c>
> >>> a =3D _
> >>> p =3D ec.fetch('Person', isDeep=3D1)[0]
> <Employee.Employee object at 0x4072d88c>
> >>> p =3D _
> >>> a.getPerson()
> <Employee.Employee object at 0x4072d88c>
> >>> a.getPerson().getId()
> 1
> >>> a.isFault()
> False
> >>> p.getAddress()
> <Modeling.FaultHandler.AccessArrayFaultHandler instance at 0x40733a4c>
> >>> list(p.getAddress())
> [<Address.Address object at 0x4071c74c>]
> >>> ec.fetch('Address', 'Person.id =3D=3D 1')
> []
> >>> ec.fetch('Address', 'Person.id =3D=3D 1', isDeep=3D1)
> []

  Wooo, I didn't even realize how serious this was.  The 'isDeep' flag
  is unfortunately of no help here, because the problem is not with
  Address and its underlying hierarchy (controlled by 'isDeep' flag) but
  because of the generated SQL statement which  obviously doesn't take
  into account the sub-entities for entity Person:

    SELECT DISTINCT t0.ID, t0.FK_PERSON=20
    FROM ADDRESS t0, PERSON t1
    WHERE ( PERSON.ID =3D 1 ) AND ( ADDRESS.FK_PERSON =3D PERSON.ID )

I've just submitted bug item #1017127 at
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1017127&group=
_id=3D58935&atid=3D489335,
with your model and the corresponding code attached.

  I'll search a definitive fix soon --my current thinking being about
  the way that would allow even more complicated qualifiers to be
  correctly handled as well, such as with: person.addresses.id in [2,3]
  or w/ a qualifier traversing two or more relationships involving
  entities with sub-entities.

        Thanks a lot for the precise report,=20

-- S=E9bastien.

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

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

On Aug 24, 2004, at 10:55 PM, Sebastien Bigaret wrote:
>
>         Hi Mario and all,
>
> Mario Ruggier <ma...@ru...> wrote:

[...]

Thanks for the detailed reply! It helps me understand better what's=20
involved.... further comments below.

>> How big of shaker would it be to give the EditingContext control over
>> which database it is working with? Even if it is the same model and
>> entity namespace in memory, why not allow the EditingContext to
>> specify its connection dictionary? i.e.
>>
>> ec1 =3D EditingContext(connDict1)
>> ec2 =3D EditingContext(connDict2)
>>
>> I guess EditingContext could also grow an optional model
>> parameter... for when the system will support more than the
>> defaultModel.
>>
>> For EditingContexts that inherit from another, they would need to
>> exist in the same db context, so they will be obliged to use their
>> parent's connection dictionary...
>>
>
> NB: I'll answer here as if you suggested that we could have entities
>     sharing the same name in different model having different=20
> connection
>     dict; this is equivalent to what you say if we consider that a=20
> model
>     and its connection dict. *cannot* be separated --later in the post
>     I'll explain why they cannot be decorrelated.

Yes, exactly... a model instance cannot change its connection=20
dictionary!
I think what I was saying, but without the intimate knowledge of the=20
internals of the framework to be so precise, is for a model "class" to=20=

be instantiated at EditingContext() time, as opposed to model load time=20=

(this will give you the model "class"... ).

>   The real problem here is that you're gonna have objects =
corresponding
>   different entities, all named Document but living in different
>   database. Say you have database DB1 and DB2, you suggest that we can
>   have at runtime objects doc1 and doc2, resp. being object for=20
> entities
>   Document in DB1 and Document in DB2.
>
> Now you'll see the real problem if you realize that each object is
> uniquely identified by its GlobalID.  And a GlobalID is the =
combination
> od an entity name and its PK value(s).  If obj1 and obj2 and the same
> PK, then they will get the same gID.

But, is this simply a matter of changing the algorithm of how a GID is=20=

calculated?
What if you throw in for example the database name as part of that=20
calculation?
Then, two objects may have the same entity name, same model name, same=20=

PK even... but if they come from a different db, there will not be any=20=

ambiguity... Note that this should also allow for the possibility to=20
have the same object from the same database but in two distinct=20
EditingContexts (not one that inherits from the other), to be correctly=20=

identified by the framework as the same object.

> The consequences are, as expected,
> devastative: snapshots are all mixed up, faults will pick up from the=20=

> db
> cache some data that in fact belongs to another database, etc...
>
>   In brief: your suggestion requires that the entities' names live in =
a
>   separate namespace, or put differently, that an entity is identified=20=

> by
>   its name and its model's name.

Yes, entities' names should be in a different namespace... but, I would=20=

go even further, and suggest also that models live in a separate=20
namespace, defined by the database instance. Thus, you can instantiate=20=

the same model **exactly**, but bound to different databases.

> Alas, the whole framework has been
>   coded with the idea of unique, distinct entities names, so while =
this
>   is possible, and while this could be added as a TODO item, this
>   definitely won't come up as a priority item for long :/

Certainly, and this is exactly the the kind of feedback I'm looking for=20=

when I put out this suggestion... I want to understand better if the=20
idea makes any sense, if having such a way of initialising an EC brings=20=

other advantages or disadvantages, and how difficult it is to modify=20
the framework so drastically.

I cannot appreciate how much work such a thing could be, but from what=20=

you say above I suspect it may be less than I thought ;)

In any case, I think it would be too early to add this as a TODO item=20
as yet, as further poking and contemplation is probably a good idea.=20
Anyone else following this issue have an opinion?

>> In fact this reminds me of a remark some months ago, about extracting
>> the connection dictionary out of the model altogether, where I had
>> claimed, without really substantiating it, that it does not seem that
>> that is where the connection dictionary belongs... ;)
>
> I strongly disagree here: the connection dictionary does belong to the
> model: this is entity-relationship modeling, entities describe classes
> stored in databases.  Or, if you prefer: as soon as an object is
> fetched, the model is tightly bound to its connection dictionary: its
> connection dictionary becomes a read-only attribute.  So, even if the
> values for the conn.dict. can be specified elsewhere (as you =
suggested,
> and as it was implemented w/ MDL_DB_CONNECTIONS_CFG since), it is a
> constituent part of the model.

Yes, this emphasises what what said above.... once an object is=20
fetched, the model is bound to its conn dictionary... i.e to the=20
database. So, if the db can be specified at EC() creation time, then=20
(conceptually, at least ;-\ ) there need not be any GID clashing=20
between objects coming form the same model and the same entity...

> -- S=E9bastien.


Thanks again!

mario

Re: [Modeling-users] Fetching limited numbers of rows

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

On 24 Aug 2004 23:14:05 +0200, Sebastien Bigaret
<sbi...@us...> wrote:
>=20
>   The status is: wait for comments ;)  It seems that some of you out ther=
e
>   use this patch, could you please comment? In particular:
>=20
>      | Current limitations are:
>      |
>      |   - it is available/tested for Postgresql and MySQL only
>      |
>      |   - parameter isDeep shouldn"t be set w/ fetch slices and/or with
>      |     sort orderings,
>      |
>      |   - inserted (unsaved) objects will appear at the end of each
>      |     result set when limit and/or orderBy is set.  is the
>      |     limitation of having inserted objects
>=20
>   Do you find this annoying?  With which database adaptor(s) do you use
>   it?  I'm asking this because it's out there for a long time, and it's
>   probably time to integrate it into the main trunk (geez, I can't
>   believe the original proposal was more than a year ago!)

I'm using this patch in every single project I'm using Modeling in
(that is one standalone and three integrated in zope). Always with
postgres; if/when one of my customers needs support for this in
something else, I'll find a way for them to sponsor the development :)
(or if cimarr=F3n/luca goes with sqlite, I'll do it on my own steam).

What I'm trying to say is that the first limitation isn't an issue for
me because postgres is my preferred database anyway; the third
limitation isn't really an issue because I have yet to come across a
use case where you insert an object and then request an ordered or
limited list of those same objects without having done a saveChanges
beforehand.

The second limitation comes as a surprise; trying it out, I see that
the problem is that isDeep performs two selects on the database,
instead of one; this is, I guess, so AdaptorChannel doesn't have to
know about it. However, the function needed in DataBaseContext to do
this merging, it seems to me, is SortOrdering's
__compareUsingKeyOrderArray__; the patch is obvious, but that function
has too many underscores for me to call it blithely from another
module. Also, doing it efficiently might be more complicated, because
each call to __compareUsingKeyOrderArray__ might be expensive as it
stands.

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

Re: [Modeling-users] toOne relationship returns base class instead of subcl

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

On 29 Jul 2004 10:30:02 +0200, Sebastien Bigaret
<sbi...@us...> wrote:
> 
>   Again, could you be a little more explicit, or exhibit a short
> example?  Sorry for getting back on this, but the only way I think this
> can happen is the one I already posted (see below); if it's not the
> case, this is a serious bug I definitely do not want to let escape.

sorry for the delay in answering, and the confusion when doing so. I
feel terribly embarrassed :(

HOWever, here goes.

With the attached model (which is ugly, and breaks some of your naming
conventions, but I just hacked out the attributes and renamed things
from the model being used by a team I'm helping to get up to speed),
using vainilla MDL 0.9-pre17.1 and NF 0.7:


>>> from Modeling.EditingContext import EditingContext
>>> import Store
>>> ec=EditingContext()
>>> ec.fetch('Address')[0]
<Address.Address object at 0x4071c74c>
>>> a = _
>>> p = ec.fetch('Person', isDeep=1)[0]
<Employee.Employee object at 0x4072d88c>
>>> p = _
>>> a.getPerson()
<Employee.Employee object at 0x4072d88c>
>>> a.getPerson().getId()
1
>>> a.isFault()
False
>>> p.getAddress()
<Modeling.FaultHandler.AccessArrayFaultHandler instance at 0x40733a4c>
>>> list(p.getAddress())
[<Address.Address object at 0x4071c74c>]
>>> ec.fetch('Address', 'Person.id == 1')
[]
>>> ec.fetch('Address', 'Person.id == 1', isDeep=1)
[]

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

[Modeling-users] Re: is this a bug in modeling?

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

sorry, guys, please ignore. Next time I'll actually read the mail I've
brain-flagged for homework before working on it.

Again, sorry for the wasted time. I'll try to address the actual issue
I was trying to answer shortly.

On Mon, 23 Aug 2004 10:50:27 -0300, John Lenton <jl...@gm...> wrote:
> Hi all.
> 
> I've been owing you this for a while now.
> 
> The attached model, with Modeling 0.9-pre16 + sortBy/limit patch, and
> 0.9-pre17.1 + sortBy/limit + quoted entities patch, produces the same
> (bad?) behaviour. I can test it with a plain 0.9-pre17.1 if you think
> it's needed.
> 
> The behaviour is this: when an attribute is requested on a fault that
> stands in for an object that is a subclass of the target of the
> relation, and that attribute isn't present in the base class, an
> exception is raised. Thus:
> 
> >>> from Modeling.EditingContext import EditingContext
> >>> ec=EditingContext()
> >>> import Store
> >>> p=ec.fetch('Address')[0].getPerson()
> >>> p.isFault()
> True
> >>> p.getTag()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> AttributeError: Person instance has no attribute 'getTag'
> >>> p.getId()
> 1
> >>> p.isFault()
> False
> >>> p.getTag()
> 'foo'
> >>>
> 
> 
> --
> John Lenton (jl...@gm...) -- Random fortune:
> The greatest of faults is to be conscious of none.
> 
> 
> 


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

Re: [Modeling-users] Fetching limited numbers of rows

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

        Hi Dennis and all,

  To all: if you're using the "Fetch slices and sort orderings" patch,
  I need your feedback, see at end of msg.

Kertis, Dennis wrote:
> Is there a way to tell Modeling to only fetch the first N rows?=A0 Ideall=
y,
> I'd like to be able to specify an offset and a count to do something like
> paging results of a search.

Thanks Mario for the references you posted, I appreciate not having to
search the archives ;)=20

  As Mario already answered, there is a patch doing what you want
  (offset and count in ec.fetch()) You'll find example in the announce,
  hopefully you'll find this useful, and if you need more informations
  then do not hesitate to ask.

Related announce is at:
  http://sourceforge.net/mailarchive/message.php?msg_id=3D7163083
And the patch is at:
  http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D892454&group=
_id=3D58935&atid=3D489337

Mario Ruggier <ma...@ru...> wrote:
> Hi, there were a few discussions on this a while back, including a pretty
> well-defined proposal to add offset and paging capabilities. Sebastien had
> also worked on it in a branch, but I do not know what the status of that =
is
> now.=20

  The status is: wait for comments ;)  It seems that some of you out there
  use this patch, could you please comment? In particular:

     | Current limitations are:
     |=20
     |   - it is available/tested for Postgresql and MySQL only
     |=20
     |   - parameter isDeep shouldn"t be set w/ fetch slices and/or with
     |     sort orderings,
     |=20
     |   - inserted (unsaved) objects will appear at the end of each
     |     result set when limit and/or orderBy is set.  is the
     |     limitation of having inserted objects

  Do you find this annoying?  With which database adaptor(s) do you use
  it?  I'm asking this because it's out there for a long time, and it's
  probably time to integrate it into the main trunk (geez, I can't
  believe the original proposal was more than a year ago!)

-- S=E9bastien.


Mario Ruggier <ma...@ru...> wrote:
> Search the mailing list archive for "offset"... but the main thread about
> this was:
>=20
> API cleanup proposal =A0
> http://sourceforge.net/mailarchive/message.php?msg_id=3D5142917
>=20
> limiting the amount of objects retrieved =A0
> http://sourceforge.net/mailarchive/message.php?msg_id=3D7163083
>=20
> limit
> http://sourceforge.net/mailarchive/message.php?msg_id=3D4159154
>=20
> mario

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

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

        Hi Mario and all,

Mario Ruggier <ma...@ru...> wrote:
[...]
> Anyhow, w.r.t. the initial argument of this thread, what you suggest, i.e=
. to
> dynamically create as many models as you need but with class names done w=
ith
> Table_ID, seems rather opaque and awkward to me...

  Well, awkward I don't know, probably a matter of taste! but anyhow it
  was not my suggestion, it was the initial requirement: Delio wants a
  database per user. Each of these database needs to be uniquely defiend
  within the server, and I think that naming each of them after the
  user/login name is quite straightforward ;)

Now, since all entities live in a single namespace, then they need to be
uniquely defined as well --that's why they are also named after the
user's name, the only reason, but also a very strong one.

> How big of shaker would it be to give the EditingContext control over
> which database it is working with? Even if it is the same model and
> entity namespace in memory, why not allow the EditingContext to
> specify its connection dictionary? i.e.
>=20
> ec1 =3D EditingContext(connDict1)
> ec2 =3D EditingContext(connDict2)
>=20
> I guess EditingContext could also grow an optional model
> parameter... for when the system will support more than the
> defaultModel.
>=20
> For EditingContexts that inherit from another, they would need to
> exist in the same db context, so they will be obliged to use their
> parent's connection dictionary...
>=20

NB: I'll answer here as if you suggested that we could have entities
    sharing the same name in different model having different connection
    dict; this is equivalent to what you say if we consider that a model
    and its connection dict. *cannot* be separated --later in the post
    I'll explain why they cannot be decorrelated.


  The real problem here is that you're gonna have objects corresponding
  different entities, all named Document but living in different
  database. Say you have database DB1 and DB2, you suggest that we can
  have at runtime objects doc1 and doc2, resp. being object for entities=20
  Document in DB1 and Document in DB2.

Now you'll see the real problem if you realize that each object is
uniquely identified by its GlobalID.  And a GlobalID is the combination
od an entity name and its PK value(s).  If obj1 and obj2 and the same
PK, then they will get the same gID.  The consequences are, as expected,
devastative: snapshots are all mixed up, faults will pick up from the db
cache some data that in fact belongs to another database, etc...

  In brief: your suggestion requires that the entities' names live in a
  separate namespace, or put differently, that an entity is identified by
  its name and its model's name.  Alas, the whole framework has been
  coded with the idea of unique, distinct entities names, so while this
  is possible, and while this could be added as a TODO item, this
  definitely won't come up as a priority item for long :/

> In fact this reminds me of a remark some months ago, about extracting
> the connection dictionary out of the model altogether, where I had
> claimed, without really substantiating it, that it does not seem that
> that is where the connection dictionary belongs... ;)

I strongly disagree here: the connection dictionary does belong to the
model: this is entity-relationship modeling, entities describe classes
stored in databases.  Or, if you prefer: as soon as an object is
fetched, the model is tightly bound to its connection dictionary: its
connection dictionary becomes a read-only attribute.  So, even if the
values for the conn.dict. can be specified elsewhere (as you suggested,
and as it was implemented w/ MDL_DB_CONNECTIONS_CFG since), it is a
constituent part of the model.


-- S=E9bastien.

[Modeling-users] is this a bug in modeling?

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

Hi all.

I've been owing you this for a while now.

The attached model, with Modeling 0.9-pre16 + sortBy/limit patch, and
0.9-pre17.1 + sortBy/limit + quoted entities patch, produces the same
(bad?) behaviour. I can test it with a plain 0.9-pre17.1 if you think
it's needed.

The behaviour is this: when an attribute is requested on a fault that
stands in for an object that is a subclass of the target of the
relation, and that attribute isn't present in the base class, an
exception is raised. Thus:

>>> from Modeling.EditingContext import EditingContext
>>> ec=EditingContext()
>>> import Store
>>> p=ec.fetch('Address')[0].getPerson()
>>> p.isFault()
True
>>> p.getTag()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: Person instance has no attribute 'getTag'
>>> p.getId()
1
>>> p.isFault()
False
>>> p.getTag()
'foo'
>>>


-- 
John Lenton (jl...@gm...) -- Random fortune:
The greatest of faults is to be conscious of none.