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

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

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

John Lenton <jl...@gm...> wrote:
[...]
> actually, what's biting me is this (I'm translating from a different
> model into this one that is similar to the example, for clarity and
> brevity; I hope I don't muss ep):
>=20
>     >>> [i.getPerson().getId() for i in ec.fetch('Address')]
>     [4, 5]
>     >>> ec.fetch('Address', 'person.id =3D=3D 4')
>     []
>=20
> in trying to simplify this last time I got the behaviour above, which
> I misinterpreted as the same thing.

Quickly replying here: this is absolutely not normal, and it would help
a lot if you could provide a sample model, code and data (sal dump is
ok).

Or maybe you were trying something like this? ->

>>> [i.getPerson().getId() for i in ec.fetch('Address')]
[4, 5]
>>> ec.fetch('Person', id =3D=3D 4')
[]

instead of:
>>> ec.fetch('Person', id =3D=3D 4', isDeep=3D1) # fetch the whole inheritc=
e tree
[<PhysicalPerson instance at 0x...>]


-- S=E9bastien.

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

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

On 23 Jul 2004 15:02:00 +0200, Sebastien Bigaret
<sbi...@us...> wrote:
> 
> 
>   Now you'll see that the discussion "ended" there with an open
>   question, about if and how this could/should be changed. Time to
>   rediscuss this I guess, huh?

ok, I've got no self-control, and I read the post. I then added the
following __getattr__ to CustomObject---I'm not at all certain this is
where it belongs, but it worked for me :) Not in production, and not
tested, but I thought I'd post it anyway

It does some magic with sys._getframe to ensure it's not called
recursively; it does it after checking the attribute doesn't start
with an underscore---which I'm not certain is ok.

  def __getattr__(self, attr):
    if attr.startswith('_'):
      raise AttributeError
    f = sys._getframe()
    if f.f_code is f.f_back.f_code:
      raise AttributeError
    print >> sys.stderr, "*** faulting object %s: %s called" % (self, attr)
    self.willRead()
    return getattr(self, attr)
    
if this is the kind of thing we're talking about, I see no problem
with it---the default behaviour is preserved due to the raising of
AttributeErrors, and it's not *too* expensive. The _getframe magick
isn't essential, but it helps.

This still didn't fix the other issue, however...

-- 
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 23 Jul 2004 15:02:00 +0200, Sebastien Bigaret
<sbi...@us...> wrote:
> 
> John Lenton <jl...@gm...> wrote:
> > in the model
> >
> >      Person
> >        / \
> >         |
> >   PhysicalPerson <---->> Address
> >
> > querying an Address for its PhysicalPerson returns Person instances,
> > which was unexpected (for me, at least). Is this correct, or is it a
> > bug?
> 
> If you mean that, having an address 'addr', addr.getPerson() has class
> 'Person', yes, this is intended, as long as addr.getPerson().isFault()
> is True. As soon as you'll need an addr's person property the fault will
> be fired and you'll get the correct class for addr.getPerson().

actually, what's biting me is this (I'm translating from a different
model into this one that is similar to the example, for clarity and
brevity; I hope I don't muss ep):

    >>> [i.getPerson().getId() for i in ec.fetch('Address')]
    [4, 5]
    >>> ec.fetch('Address', 'person.id == 4')
    []

in trying to simplify this last time I got the behaviour above, which
I misinterpreted as the same thing.

> Now you may wonder why this is like this. We discussed this here:
> https://sourceforge.net/mailarchive/forum.php?thread_id=3457563&forum_id=10674

ok. Will read up---tomorrow (deadlines...!)

-- 
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...>]

John Lenton <jl...@gm...> wrote:
> in the model
>=20
>      Person
>        / \
>         |
>   PhysicalPerson <---->> Address
>=20
> querying an Address for its PhysicalPerson returns Person instances,
> which was unexpected (for me, at least). Is this correct, or is it a
> bug?

If you mean that, having an address 'addr', addr.getPerson() has class
'Person', yes, this is intended, as long as addr.getPerson().isFault()
is True. As soon as you'll need an addr's person property the fault will
be fired and you'll get the correct class for addr.getPerson().


Now you may wonder why this is like this. We discussed this here:
https://sourceforge.net/mailarchive/forum.php?thread_id=3D3457563&forum_id=
=3D10674


See esp. the third post dated 2003-11-15 20:40.  While the example taken
there involves a relationship pointing from a subclass to its root
class, you'll see that you get exactly the same kind of problem if you
add a class Photo such as:      Photo <<---> Person


  Now you'll see that the discussion "ended" there with an open
  question, about if and how this could/should be changed. Time to
  rediscuss this I guess, huh?


-- S=E9bastien.


PS: BTW the interesting methods on this topic:=20

        DBChannel.fetchObject() calling DBContext.initializeObject(),
        which in particular populates the object's toOne properties with
        DBContext.faultForGlobalID().

  and this particular behaviour is tested in:=20
        test_EC_Global_Inheritance.test_02_toOneFault()

[Modeling-users] toOne relationship returns base class instead of subclass?

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

in the model

     Person
       / \
        |
  PhysicalPerson <---->> Address

querying an Address for its PhysicalPerson returns Person instances,
which was unexpected (for me, at least). Is this correct, or is it a
bug?

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

Re: [Modeling-users] Switching to a 3-clause BSD-like licence

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

        Hi all,

Sebastien Bigaret <sbi...@us...> wrote:
> The switch to the BSD-like license will be made in two parts.
>=20
>   As far as the NotificationFramework is concerned, a new release will
>   be made in the next coming days under the new licence.
>=20
> The Modeling framework will also switch to the new licence in the coming
> week, but on the CVS main trunk only. The next release will be a v0.9
> release candidate, however there is no precise date for this release
> yet.  Until it is released, anyone will be able to get a BSD-licensed
> version of the framework through anonymous cvs on sourceforge.
>=20
>   Every step will obviously be announced here when done.

Now that the NF has been released under such a license, I'm pleased to
announce that the Modeling framework is now covered by the same BSD
license, which can be viewed here:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/modeling/ProjectModeling/L=
ICENSE?rev=3D1.3

  There's no release planned yet, but you can get your own version by
  anonymous CVS --see https://sourceforge.net/cvs/?group_id=3D58935 for
  detailed instructions.


-- S=E9bastien.

Re: [Modeling-users] Interfaces

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

This initially came from zope (not z3 but some good old z2). When I
began coding the framework, I used interfaces as a guideline for
forthcoming implementations. I also used zope's Interface class to make
some verifications --there's an example of this in KeyValueCoding, look
at the end:

  try:
    verify_class_implementation(KeyValueCodingInterface, KeyValueCoding)
  except:
    pass


Now back to z3 and twisted, I wish I had the time to discover those
masterpieces, but unfortunately that's not (still!) the case...  BTW if
any of you have (even little) experiences w/ MDL and z3 or twisted, I'm
very interested in hearing your stories!

-- S=E9bastien.


Ernesto Revilla <er...@si...> wrote:
> Dear S=E9bastien,
>=20
> in the interface files, there is a:
>=20
> try:
>   from Interface import Base
> except:
>   class Base:
>     pass
>=20
> I can't any Interface.py.   I know Twisted and Zope z3 components have so=
me
> interfaces. Is this aimed at one of these or your own stuff? In the
> implementations we have something like:
>=20
> from Modeling.interfaces.Adaptor import IAdaptor
> ...
> class Adaptor:
>      __implements__ =3D (IAdaptor,)
> ...
>=20
> (Sounds very much like Twisted...)
>=20
>=20
> Erny

Re: [Modeling-users] Re: initial value of required fields

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

On 21 Jul 2004 19:34:35 +0200, Sebastien Bigaret
<sbi...@us...> wrote:
>=20
> John Lenton <jl...@gm...> wrote:
> > On Wed, 21 Jul 2004 12:17:42 -0300, John Lenton <jl...@gm...> wro=
te:
> > > S=E9bastien, would having an option for required fields being
> > > initialized to non-null values be ok with you?
> > >
> > > In a project I'm overseeing the team finds it unnatural that a
> > > required field that isn't filled in won't raise an exception, and I
> > > thought the easy way out (while I thump them with a
> > > validate-everything stick) would be to make it optional...
>=20
> Sorry, but I'm not sure to understand: are you facing situations where
> objects with None value in required field did not make ec.saveChanges()
> raise?
>=20
> > FWIW, now they're using defaultValue to do the same thing... and maybe
> > that's enough.
>=20
> If tyhis is just a matter of initialization then yes, the default values
> should be enough, or am I missing something?

no, you're not. Just initialization. The first mail went out before I
was reminded of defaultValue... and further tests confirmed that it
was what we wanted. Should've let you know; sorry.

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

Re: [Modeling-users] Re: initial value of required fields

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

John Lenton <jl...@gm...> wrote:
> On Wed, 21 Jul 2004 12:17:42 -0300, John Lenton <jl...@gm...> wrote:
> > S=E9bastien, would having an option for required fields being
> > initialized to non-null values be ok with you?
> >=20
> > In a project I'm overseeing the team finds it unnatural that a
> > required field that isn't filled in won't raise an exception, and I
> > thought the easy way out (while I thump them with a
> > validate-everything stick) would be to make it optional...

Sorry, but I'm not sure to understand: are you facing situations where
objects with None value in required field did not make ec.saveChanges()
raise?

> FWIW, now they're using defaultValue to do the same thing... and maybe
> that's enough.

If tyhis is just a matter of initialization then yes, the default values
should be enough, or am I missing something?

-- S=E9bastien.

[Modeling-users] Interfaces

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

Dear Sébastien,

in the interface files, there is a:

try:
  from Interface import Base
except:
  class Base:
    pass

I can't any Interface.py.   I know Twisted and Zope z3 components have 
some  interfaces. Is this aimed at one of these or your own stuff? In 
the implementations we have something like:

from Modeling.interfaces.Adaptor import IAdaptor
...
class Adaptor:
     __implements__ = (IAdaptor,)
...

(Sounds very much like Twisted...)


Erny



---
avast! Antivirus: Saliente mensaje limpio.
Base de datos de Virus (VPS): 0430-1, 19/07/2004
Comprobado en: 21/07/2004 19:03:05
avast! tiene los derechos reservados (c) 2000-2004 ALWIL Software.
http://www.avast.com

[Modeling-users] Re: initial value of required fields

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

On Wed, 21 Jul 2004 12:17:42 -0300, John Lenton <jl...@gm...> wrote:
> S=E9bastien, would having an option for required fields being
> initialized to non-null values be ok with you?
>=20
> In a project I'm overseeing the team finds it unnatural that a
> required field that isn't filled in won't raise an exception, and I
> thought the easy way out (while I thump them with a
> validate-everything stick) would be to make it optional...

FWIW, now they're using defaultValue to do the same thing... and maybe
that's enough.

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

[Modeling-users] initial value of required fields

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

S=E9bastien, would having an option for required fields being
initialized to non-null values be ok with you?

In a project I'm overseeing the team finds it unnatural that a
required field that isn't filled in won't raise an exception, and I
thought the easy way out (while I thump them with a
validate-everything stick) would be to make it optional...

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

Re: [Modeling-users] Debugging mode?

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

On Tue, 20 Jul 2004 23:10:02 +0300, Andrey Lebedev <an...@mi...> wrote:
>=20
> Is there any sort of debugging mode in modeling framework that makes it
> possible to see SQL statements performed by framework internals?

see MDL_ENABLE_DATABASE_LOGGING in

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

and s=E9bastien's comments in

http://sourceforge.net/mailarchive/forum.php?thread_id=3D3901927&forum_id=
=3D10674

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

[Modeling-users] Debugging mode?

[Andrey L. <an...@mi...>]

Hello,

Is there any sort of debugging mode in modeling framework that makes it
possible to see SQL statements performed by framework internals? 

I'd like to be at least aware what my app is doing:)

Thanks.


-- 
Andrey Lebedev aka -.- . -.. -.. . .-.
Software engineer at UAB Mikromarketingas (http://micro.lt)
Homepage: http://micro.lt/~andrey/
Jabber ID: ke...@ja...

Re: [Modeling-users] Using modeling framework in long run

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

John Lenton <jl...@gm...> wrote:
> On 19 Jul 2004 21:00:29 +0200, Sebastien Bigaret wrote:
> >=20
> > Second, the framework does not anymore relies that heavily on code
> > generation, but how could you know since this hasn't been publicly
> > announced yet :/ ... (esp. because it's not fully documented)
>=20
> I'm not clear on one issue: how do I add validators to dynamicly
> created packages?

You add validators, along w/ any necessary business logic, by defining your
own classes. Now I guess the question is how ;)

  The simplest way is w/ the metaclass approach, when you declare your
  own class with '__metaclass__=3DCustomObjectMeta' (also look at the
  sections beginning with <<if __name__ =3D=3D...>> in dynamic.py for
  examples)

There is an other solution if you want to stay away from metaclasses,
but it requires more work. For example:

  Say you want to have classes in Package.Modules.Classes:

  - in your package's __init__.py:

    * load the model,
    * change its packageName into 'PackageBase' (instead of Package)
    * build the classes (either with dynamic.build() or build_with_metaclas=
s())
    * revert the model's packageName to its original value 'Package'

  - then, define a subclass for each entity, inheriting from
    'PackageBase.Module.Class'. They'll inherit from the dynamically
    built classes, the framework will use the derived classes which hold
    the dedicated validators, etc.

-- S=E9bastien.


> --=20
> John Lenton (jl...@gm...) -- Random fortune:
> bash: fortune: command not found
Hey, keep an eye on your bash, looks like it is trying to escape and
seek fortune ;P

Re: [Modeling-users] Using modeling framework in long run

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

On 19 Jul 2004 21:00:29 +0200, Sebastien Bigaret
<sbi...@us...> wrote:
> 
> Second, the framework does not anymore relies that heavily on code
> generation, but how could you know since this hasn't been publicly
> announced yet :/ ... (esp. because it's not fully documented)

I'm not clear on one issue: how do I add validators to dynamicly
created packages?

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

Re: [Modeling-users] Using modeling framework in long run

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

        Hi Andrey,

  First at all, thanks for your interest!

The problem here is obviously that the default option (-C for
--compact-generation-scheme, see mdl_generate_python_code.py -h) is
nothing more than a example showing what are the basics for binding a
class to the framework. But nobody probably uses it in a real
dev. effort because it's difficult to deal with such a scheme when the
underlying DB-schema changes a lot --just what you noticed and felt
unconfortable with.

  As John Lenton has already explained, the -B switch in code generation
  will be a great help for you, since you can put all your code in
  subclasses of auto-generated classes which are put in a dedicated
  package (MDL/).

You can also look at John's original post and the corresponding thread
at:
https://sourceforge.net/mailarchive/forum.php?thread_id=3851852&forum_id=10674



Second, the framework does not anymore relies that heavily on code
generation, but how could you know since this hasn't been publicly
announced yet :/ ... (esp. because it's not fully documented)

--> dynamic, on-the-fly creation of package is available in the last 
    release 0.9pre17; look for a file named doc/README.dynamic.txt, also
    available here:
http://cvs.sourceforge.net/viewcvs.py/modeling/ProjectModeling/Modeling/doc/README.dynamic.txt?rev=1.1&view=auto

Using that feature allows you to bypass the modification of the needed
code since dynamic generation will always use your model to dynamically
create your classes.  Just a little note, Ernesto Revilla reported some
problems regarding properties and inheritance, so you may not want to
use properties right now; more details in Ernesto's original post here:
https://sourceforge.net/mailarchive/forum.php?thread_id=5035017&forum_id=10674

  Feel free to ask for more if some points remain obscure!

-- Sebastien.


Andrey Lebedev <an...@mi...> wrote:
> Hello,
> 
> I'm currently evaluating several object-relational mappings available
> for python and I thing modeling is one of the best among them. However,
> I need some clarification on how projects, that are based on modeling
> framework, are supposed to be maintained.
> 
> As far as I understand, the framework is heavily relies on code
> generation. Developer creates single XML or python file, describing data
> model and then generates SQL schemas and python sources. Judging from
> comments inside those generated python sources, they are intended to be
> modified by developers after generation.
> 
> But what happens when database schema should be changed? What if there
> are data in database that can't be lost just by deleting and recreating
> tables? How to keep generated files' customizations after model
> modifications?
> 
> The simplest procedure I can come up with is: 
> 
>   1. Change database on sql server using regular tools 
> 
>   2. Change generated files by adding get<attr>, set<attr> methods and
> 	 other necessary functions.
> 
>   3. Change model file (actually I'm not sure it is nesessary)
> 
> The procedure is somewhat too complex, expecially because generated
> python modules are not elementary and consist of relatively complex
> statements to be written by hand each time database schema changes.
> 
> So, the question is: what, generally I have to do when I have, say,
> developer and production project installations and I want add new column
> to a table? How do you handle such situations?
> 
> Thanks in advance.
> 
> -- 
> Andrey Lebedev aka -.- . -.. -.. . .-.
> Software engineer at UAB Mikromarketingas (http://micro.lt)
> Homepage: http://micro.lt/~andrey/
> Jabber ID: ke...@ja...

Re: [Modeling-users] Using modeling framework in long run

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

On Mon, 19 Jul 2004 00:41:33 +0300, Andrey Lebedev <an...@mi...> wrote:
> The simplest procedure I can come up with is:
> 
>   1. Change database on sql server using regular tools
> 
>   2. Change generated files by adding get<attr>, set<attr> methods and
>          other necessary functions.
> 
>   3. Change model file (actually I'm not sure it is nesessary)
> 
> The procedure is somewhat too complex, expecially because generated
> python modules are not elementary and consist of relatively complex
> statements to be written by hand each time database schema changes.
> 
> So, the question is: what, generally I have to do when I have, say,
> developer and production project installations and I want add new column
> to a table? How do you handle such situations?

1. Change model file
2. Regenerate python code, using -B (you must've done this the first time too)

    The -B option gives you the validators (the business logic) in
files in the base
    directory of the generated package, and set/get/add/etc. (the
"pure" generated
    code that you don't add to).

3. Alter the database.

this leaves your python code without the new validators, which you
might have to add, but it's significantly less trouble than what you
described.

If your validators get very complex, you might find it easyer to put
them in a mixin class, and modify the generated classes via the mixin
(which would normally be just one line per class you need to add).

Also, if you keep all the revisions of the original, unmodified
generated code, you can update the validators automatically with
diff3.

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

[Modeling-users] Using modeling framework in long run

[Andrey L. <an...@mi...>]

Hello,

I'm currently evaluating several object-relational mappings available
for python and I thing modeling is one of the best among them. However,
I need some clarification on how projects, that are based on modeling
framework, are supposed to be maintained.

As far as I understand, the framework is heavily relies on code
generation. Developer creates single XML or python file, describing data
model and then generates SQL schemas and python sources. Judging from
comments inside those generated python sources, they are intended to be
modified by developers after generation.

But what happens when database schema should be changed? What if there
are data in database that can't be lost just by deleting and recreating
tables? How to keep generated files' customizations after model
modifications?

The simplest procedure I can come up with is: 

  1. Change database on sql server using regular tools 

  2. Change generated files by adding get<attr>, set<attr> methods and
	 other necessary functions.

  3. Change model file (actually I'm not sure it is nesessary)

The procedure is somewhat too complex, expecially because generated
python modules are not elementary and consist of relatively complex
statements to be written by hand each time database schema changes.

So, the question is: what, generally I have to do when I have, say,
developer and production project installations and I want add new column
to a table? How do you handle such situations?

Thanks in advance.

-- 
Andrey Lebedev aka -.- . -.. -.. . .-.
Software engineer at UAB Mikromarketingas (http://micro.lt)
Homepage: http://micro.lt/~andrey/
Jabber ID: ke...@ja...

[Modeling-users] typo in astring docs

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

actually, probably a cut-n-paste bug.

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

Re: [Modeling-users] creating objects by name

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

I don't remember that this was asked before, anyhow here is the magic :)

(provided that the model has already been loaded into the
 defaultModelSet)

>>> import AuthorBooks
>>> from Modeling import ClassDescription
>>> cd=3DClassDescription.classDescriptionForName('Book')
>>> # get the class
... cd.classForInstances()=20
<class 'Book.Book'>
>>> from Modeling.EditingContext import EditingContext
>>> ec=3DEditingContext()
>>> # create an instance
... book=3Dcd.createInstanceWithEditingContext(ec)
<Book.Book object at 0x4103158c>
>>> # WARNING! it is NOT registered inside the EC
... print book.editingContext()
None

2 remarks:

- createInstanceWithEditingContext() completely ignores the EC, the
  object still need to be inserted into the EC afterwards. I need to
  double-check this carefully (esp. wrt DBChannel.fetchObject() if
  you're curious). Plus the documentation is incorrect, part of it
  applies to classForInstances() --esp. for the delegate part)

- the real stuff (importing the correct module and class) is done by
  EntityClassDescription.classForEntity()


-- S=E9bastien.



John Lenton <jl...@gm...> wrote:
> I'm certain this has been asked and answered before, but I can't find
> it anywhere: how can I create an object by name? By this I mean,
> instead of doing
>=20
>    from MyModel.Thing import Thing
>    a_thing =3D Thing()
>    ec.insert(a_thing)
>=20
> what magic do I use to do
>=20
>    do_magic()
>    a_thing =3D more_magic('Thing')
>    ec.insert(a_thing)
>=20
> ?
>=20
>=20
> --=20
> John Lenton (jl...@gm...) -- Random fortune:
> bash: fortune: command not found

[Modeling-users] creating objects by name

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

I'm certain this has been asked and answered before, but I can't find
it anywhere: how can I create an object by name? By this I mean,
instead of doing

   from MyModel.Thing import Thing
   a_thing = Thing()
   ec.insert(a_thing)

what magic do I use to do

   do_magic()
   a_thing = more_magic('Thing')
   ec.insert(a_thing)

?


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

[Modeling-users] patch for quoted entities, attributes

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

Attached is a patch that quotes entites and attributes in the sql. It
has several problems, still:

  - I haven't fixed the tests (and I'm not certain it's even possible
    without rewriting them), so if you use postgres suddenly a whole
    slew of tests fail.

  - Schema generation *almost* works: I'm not quoting the drop
    statements for the primary key indexes.

  - I changed an unrelated bit: I set useAllCaps to default to 0 in
    Entity. This makes the previous bug hide under the carpet, plus
    you don't have to quote things when using 'psql' (the latter is the
    reson for this change).

  - No documentation.

  - Only done for postgres (but the per-adapter changes are small)

  - Some of the lines are way too long, especially when cutting a line
    would mean creating an intermediate object---in those cases I
    defer to S=E9bastien to decide if it's worth it---or when the original
    was pretty long to start with :)

however, it's working for me (so far!), and I'm using it for
development.=20

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

Re: [Modeling-users] state checking

[Duncan M. <du...@ad...>]

Sebastien,

Thanks again; this works perfectly -- just what we needed. In case =20
anyone else has similar needs, here's how we are using it:

class EditorContext(EditingContext):
     '''
     This class is a wrapper for EditingContext, whose sole purpose is =
to
     set the optimistic locking behind the scenes and provide a simple
     interface to users of this code.
     '''
     def __init__(self):
         EditingContext.__init__(self)
         self.snapshot_sum =3D ''
         self.protect_data =3D 0

     def fetchData(self, entityName, qualifier=3DNone, isDeep=3D0, =20
rawRows=3D0):
         fs=3DFetchSpecification(entityName, qualifier=3DNone, =20
sortOrderings=3D(), distinctFlag=3D0, deepFlag=3D0, hints=3D{})
         =20
dbContext=3Dself.rootObjectStore().objectStoreForFetchSpecification(fs)
         dbContext.setUpdateStrategy(UPDATE_WITH_OPTIMISTIC_LOCKING)
         return self.fetch(entityName, qualifier=3DNone, isDeep=3D0, =20
rawRows=3D0)

     def commitChanges(self):
         try:
             self.saveChanges()
         except Modeling.Adaptor.OptimisticLockingFailure, e:
             raise DatabaseObjectStateError, e


On Jul 6, 2004, at 2:08 PM, Sebastien Bigaret wrote:

>
> I currently have very very little time, so please excuse this too =
short
> answer.
>
> Duncan McGreggor <du...@ad...> wrote:
>> Hey folks,
>>
>> I am aware that checking for changes in a database source data is not
>> supported yet, but I am attempting to do this anyway...
>>
>> What I want to do is a fetch, and then operate on the data, then =20
>> before I
>> save the changes, fetch again to see if the source has changed at =20
>> all. I
>> have methods that do this, however... the data seems to be cached =20
>> during the
>> call to EditingContext(), as the fetch pulls the same data over and =20=

>> over,
>> not matter how much I change the source data.
>
> Fine! --> what you need here is (again!) definitely optimistic =
locking.
>
> To answer your questions: yes, row snapshots are cached, and this =
leads
> to the limitation you already noticed.  Is there an easy way to get a
> fresh snapshot? Sorry, not in the current state.
>
> I initially thought this was somewhere on a branch, but the recent
> discussion we had with Ernesto proved that this only lies on my
> hard-disk.
>
>   I believe that you want to go this way because you need it; same as
>   for Ernesto.
>
> I've put there a tarball containing the current state for optimistic
> locking:
> https://sourceforge.net/tracker/index.php?=20
> func=3Ddetail&aid=3D986122&group_id=3D58935&atid=3D489338
>
> There's a patch against the current CVS head and some additional
> files, full content is:
>
>     optimistic_locking.patch
>     Modeling/DefaultEditingContextDelegate.py
>     Modeling/EditingContextDefaultDelegate.py
>     Modeling/interfaces/EditingContextDelegate.py
>     Modeling/tests/test_EditingContext_optimistic_locking.py
>
> I'm sorry I've not enough time to comment right now, but at least it =
is
> functional; you can refer to the tests that are contained in module
> test_EditingContext_optimistic_locking.py
>
>   Hopefully this will be a good starting point for all of you needing
>   the feature; please just keep in mind this is alpha software. Any
>   feedbacks will be greatly appreciated!
>
> Last: by now I cannot give a exhaustive overview of the current
> limitations, however the tests comment some of these.  Plus, do not =
try
> to make it work w/ nested ECs unless you know what you're doing (and
> since I've no time to check this right now, I'd say I do not know what
> sort of weird effects you can get if you try this with nested ECs!).
>
> -- S=E9bastien.=

Re: [Modeling-users] state checking

[Duncan M. <py...@ad...>]

Sebastien,

Please do not apologize! This is wonderful, thank you -- I am untar'ing =20=

it right now. We understand how much work you must have to do, being =20
such an excellent coder; though you may say this tarball is only a =20
little, it is actually huge! The work it would have taken for me to do =20=

the same thing would be ridiculous... tons of appreciation! Thanks!

Duncan

On Jul 6, 2004, at 2:08 PM, Sebastien Bigaret wrote:

>
> I currently have very very little time, so please excuse this too =
short
> answer.
>
> Duncan McGreggor <du...@ad...> wrote:
>> Hey folks,
>>
>> I am aware that checking for changes in a database source data is not
>> supported yet, but I am attempting to do this anyway...
>>
>> What I want to do is a fetch, and then operate on the data, then =20
>> before I
>> save the changes, fetch again to see if the source has changed at =20
>> all. I
>> have methods that do this, however... the data seems to be cached =20
>> during the
>> call to EditingContext(), as the fetch pulls the same data over and =20=

>> over,
>> not matter how much I change the source data.
>
> Fine! --> what you need here is (again!) definitely optimistic =
locking.
>
> To answer your questions: yes, row snapshots are cached, and this =
leads
> to the limitation you already noticed.  Is there an easy way to get a
> fresh snapshot? Sorry, not in the current state.
>
> I initially thought this was somewhere on a branch, but the recent
> discussion we had with Ernesto proved that this only lies on my
> hard-disk.
>
>   I believe that you want to go this way because you need it; same as
>   for Ernesto.
>
> I've put there a tarball containing the current state for optimistic
> locking:
> https://sourceforge.net/tracker/index.php?=20
> func=3Ddetail&aid=3D986122&group_id=3D58935&atid=3D489338
>
> There's a patch against the current CVS head and some additional
> files, full content is:
>
>     optimistic_locking.patch
>     Modeling/DefaultEditingContextDelegate.py
>     Modeling/EditingContextDefaultDelegate.py
>     Modeling/interfaces/EditingContextDelegate.py
>     Modeling/tests/test_EditingContext_optimistic_locking.py
>
> I'm sorry I've not enough time to comment right now, but at least it =
is
> functional; you can refer to the tests that are contained in module
> test_EditingContext_optimistic_locking.py
>
>   Hopefully this will be a good starting point for all of you needing
>   the feature; please just keep in mind this is alpha software. Any
>   feedbacks will be greatly appreciated!
>
> Last: by now I cannot give a exhaustive overview of the current
> limitations, however the tests comment some of these.  Plus, do not =
try
> to make it work w/ nested ECs unless you know what you're doing (and
> since I've no time to check this right now, I'd say I do not know what
> sort of weird effects you can get if you try this with nested ECs!).
>
> -- S=E9bastien.
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Modeling-users mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modeling-users
>
>
>
--
Duncan M. McGreggor        mailto:du...@ad...
Systems &                  p 301.698.5032
Applications Engineer      m 301.801.0349
AdytumSolutions, Inc.      http://adytum.us