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

Re: [Modeling-users] state checking

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

I currently have very very little time, so please excuse this too short
answer.

Duncan McGreggor <du...@ad...> wrote:
> Hey folks,
>=20
> 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 before I
> save the changes, fetch again to see if the source has changed at all. I
> have methods that do this, however... the data seems to be cached during =
the
> call to EditingContext(), as the fetch pulls the same data over and 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.=20=20

  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?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:=20

    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.

[Modeling-users] state checking

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

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 before 
I save the changes, fetch again to see if the source has changed at 
all. I have methods that do this, however... the data seems to be 
cached during the call to EditingContext(), as the fetch pulls the same 
data over and over, not matter how much I change the source data.

Any pointers?


--
Duncan M. McGreggor        mailto:du...@ad...
Systems &                  p 301.698.5032
Applications Engineer      m 301.801.0349
AdytumSolutions, Inc.      http://adytum.us

[Modeling-users] state checking

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

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 before 
I save the changes, fetch again to see if the source has changed at 
all. I have methods that do this, however... the data seems to be 
cached during the call to EditingContext(), as the fetch pulls the same 
data over and over, not matter how much I change the source data.

Any pointers?


--
Duncan M. McGreggor        mailto:du...@ad...
Systems &                  p 301.698.5032
Applications Engineer      m 301.801.0349
AdytumSolutions, Inc.      http://adytum.us

Re: [Modeling-users] turning off new-style classes

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

    Hi John,

  Quick answer, I've no time to check anything w/ Zope by now,
but if you want your classes to be old-style you can modify
Modeling.utils and replace:

try:
    base_object = types.ObjectType
    newclass = 1
except AttributeError:
    class base_object : pass
    newclass = 0

by:

class base_object : pass
newclass = 0

--should work: generated classes inherit from CustomObject which inherits from
base_object.

    HTH!

-- Sébastien.

John Lenton <jl...@gm...> wrote:
> is there an easy way to revert to 0.9-pre-16 behaviour of creating
> "old-style" classes? zope's security seems to choke on new-style---or
> is there a way to make it work with new-style classes?
> 
> attached is the __init__.py I use in zope... maybe somebody can
> enlighten me on a better way to do it?
> 
> /me is in total newbie mode
> 
> -- 
> John Lenton (jl...@gm...) -- Random fortune:
> bash: fortune: command not found
> 

[Modeling-users] turning off new-style classes

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

is there an easy way to revert to 0.9-pre-16 behaviour of creating
"old-style" classes? zope's security seems to choke on new-style---or
is there a way to make it work with new-style classes?

attached is the __init__.py I use in zope... maybe somebody can
enlighten me on a better way to do it?

/me is in total newbie mode

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

Re: [Modeling-users] SQLite inserts slow

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

Ernesto Revilla <er...@si...> wrote:
> Yes, I have the same opinion as Mario:
> 1. the adaptor (name) to be used should not be part of the model, but read
> in v=EDa config. file, although I know that code generation is a bit diff=
erent
> for each db adaptor. (I hope that soon dynamic will get a big push and
> within a year everyone uses dynamic, so we have no code generation phase:
> just change the config file and reinit the application, and voil=E0, you =
use
> another database backend.)

OProvided that you've not noticed that already, you'll be pleased to
know that this is already possible!  Look at the models used in the
tests: they do not have the adaptorName set, but they get it from the
files Postgresql.cfg, MySQL.cfg etc.

This is driven by the env. variable MDL_DB_CONNECTIONS_CFG, described
at: http://modeling.sourceforge.net/UserGuide/env-vars-core.html

> 2. there should be hooks on a per db adaptor base (at least, at db creati=
on
> time, and at connection time). Perhaps, which instructions to send to the
> database should be part of either a general config file with a section for
> each db adaptor, or a different config file for each db adaptor.

Agreed, I've just added this to the TODO list; BTW, I'm more inclined to
have specific python hooks that could be triggered at creation time and
at connection time.


-- S=E9bastien.

Re: [Fwd: Re: [Modeling-users] Optimistic Locking]

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

Ernesto Revilla <er...@si...> wrote:
> Thanx a lot for your comments. (Perhaps some sentences could go into the
> documentation?)

Yes, probably ;) The discussion we have on the ml is often a first draft
for the real documentation!

> The first thing: is there an easy way to use all attributes of an object =
for
> optimistic locking?

Sorry, no, but you can ask for one in PyModels!

> On the other hand, how can I easily simulate optimistic locking collisions
> within the same process? (suppose you use ZOPE which has just one process,
> but different EditingContext, and want the user to be warned, when data h=
as
> been updated by another user?)


Okay, this does not really "simulate" optimistic locking collisions,
since if a process hits a conflict you'll get an exception when
saveChanges() is triggered, however within a single process different
threads/ECs are notified when an EC saves its changes. This notification
is EditingContextDidSaveChangesNotification, which by default triggers
EditingContext.mergeChanges (which applies the changes, then re-applies
its own changes).

  After a quick check, I realize that most of the code is there around
  on my computer, but I haven't committed it to CVS nor to a branch. I
  do not have the time to check this, nor to start to have a look again
  at it by now. However, if you wish, I can post the full patch for the
  code I have here. And naturally and again, if you need optimistic
  locking, then loudly ask for it!!

        Cheers,

-- S=E9bastien.

Re: [Modeling-users] Future directions: replication and auto-increments

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

        Hi Erny,

  This particular point can be easily solevd if you could plug-in your
own algorithm to generate PK values --then they would be generated the
appropriate way. Are you going this way and would you test it if it is
implemented?

-- S=E9bastien.




PS: Oh, BTW, TemporaryGlobalIDs are identified by host, ip and time :)

Ernesto Revilla <er...@si...> wrote:
> Hi,
>=20
> when talking with some Python people, I heard about future requirements
> about multi-master replication. This is what you need if you have data sp=
lit
> over several offices and you have no 100% uptime links. Multi-master
> replication is available in mysql, but Postgresql still is lacking this
> feature. I think Oracle as it also.
>=20
> The problems you can have with multi-master replication are the update
> collisions. But these may not be very usual in real scenarios, depending =
how
> data is organized.
>=20
> The first problem of all is that we can't use auto-increment (serial)
> fields. So we have to use our own function to produce this. For this to
> work, the original autoincremen field is defined as large integer, someth=
ing
> like 64 bits, where a part is reserved as a local counter and the other p=
art
> as station identifier which created the object, e.g. 16 bit station
> identifier + 48 bit counter. There are other, more complicated, algorithm=
s,
> like those which create a global unique id (GUID) bases on the Ethernet
> address and time, and distributed scenarios, where there is a process whi=
ch
> gives new hi-numbers to stations (which in turn can fragment the bits use=
d,
> say 16 into 8+8 and give their own low part hi number to other stations,
> producing a hierarchical system).
>=20
> Concluding, IDs should not be created by database systems, but by the
> middleware in a nuclear operation.
>=20
> With best regards, Erny

Re: [Modeling-users] dynamic, metaclasses and Virtual properties

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

Sender: John Lenton <jo...@ma...>

On Wed, Jun 30, 2004 at 06:21:53PM +0200, Ernesto Revilla wrote:
> Hi all,
> 
> I think that Python has a design error with properties, but it is easy 

properties are evil; stay away from them. They are usful for one thing
and one thing only: replacing buggy classes that used attributes.

IMHO :)

-- 
John Lenton (jo...@vi...) -- Random fortune:
You know what they say -- the sweetest word in the English language is revenge.
		-- Peter Beard

[Modeling-users] Future directions: replication and auto-increments

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

Hi,

when talking with some Python people, I heard about future requirements 
about multi-master replication. This is what you need if you have data 
split over several offices and you have no 100% uptime links. 
Multi-master replication is available in mysql, but Postgresql still is 
lacking this feature. I think Oracle as it also.

The problems you can have with multi-master replication are the update 
collisions. But these may not be very usual in real scenarios, depending 
how data is organized.

The first problem of all is that we can't use auto-increment (serial) 
fields. So we have to use our own function to produce this. For this to 
work, the original autoincremen field is defined as large integer, 
something like 64 bits, where a part is reserved as a local counter and 
the other part as station identifier which created the object, e.g. 16 
bit station identifier + 48 bit counter. There are other, more 
complicated, algorithms, like those which create a global unique id 
(GUID) bases on the Ethernet address and time, and distributed 
scenarios, where there is a process which gives new hi-numbers to 
stations (which in turn can fragment the bits used, say 16 into 8+8 and 
give their own low part hi number to other stations, producing a 
hierarchical system).

Concluding, IDs should not be created by database systems, but by the 
middleware in a nuclear operation.

With best regards, Erny

[Modeling-users] dynamic, metaclasses and Virtual properties

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

Hi all,

I think that Python has a design error with properties, but it is easy 
to correct this. We can see that in the following example:

class Base(object):
    _name=None
    def getName(self):
        return self._name
    def setName(self, value):
        self._name=value
    name=property(getName,setName)

class Sub(Base):
    def setName(self, value):
       print "Setting name to '%s'" % value
       Base.setName(self,value)

Ok, here we can see how Sub extends the functionality of Base. But if we do:

instance=Sub()
instance.name="a name"

Sub.setName is NOT  called.!!!   Of course, it cand, because the 
property binds directly to the methods. Now we see the Base class 
corrected, using 'virtual' properties:

class Base(object):
    _name=None
    def getName(self):
        return self._name
    def setName(self, value):
        self._name=value
    name=property(lambda s: s.getName(), lambda s, v: s.setName(v))

class Sub(Base):
    def setName(self, value):
       print "Setting name to '%s'" % value
       Base.setName(self,value)

An try again:
 >>> instance=Sub()
 >>> instance.name="a name"
Setting name to 'a name'

In Modeling, when inheriting from class created with properties 
(dynamic), it does NOT the inherited methods. Is this reasonable? 

Here I have attached a little patch for dynamic.py. I made a local 
function mkProp, so that  variable binding is correct, otherwise  it 
does not work the way it should. Just a remark about the setter. As in 
the original code, a virtual setter is created only if the attribute is 
settable in the base class. In this case, we have two alternatives: 1. 
do not create a setter, as the original code, 2. create always a virtual 
setter and the setter in the base class raises a 
ReadOnlyAttributeException. (This is was I have done in a experimental 
framework.)

Best regards, Erny

Re: [Modeling-users] SQLite inserts slow

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

Hi,

Yes, I have the same opinion as Mario:
1. the adaptor (name) to be used should not be part of the model, but 
read in vía config. file, although I know that code generation is a bit 
different for each db adaptor. (I hope that soon dynamic will get a big 
push and within a year everyone uses dynamic, so we have no code 
generation phase: just change the config file and reinit the 
application, and voilà, you use another database backend.)

2. there should be hooks on a per db adaptor base (at least, at db 
creation time, and at connection time). Perhaps, which instructions to 
send to the database should be part of either a general config file with 
a section for each db adaptor, or a different config file for each db 
adaptor.

With best regards,
Erny


Mario Ruggier escribió:

>>   While we're at it, are there other PRAGMAs that you all using
>>   sqlite think they should be controlled in the same way?
>
>
> I have not played with sqlite pragmas, so none that I can think of. 
> But, this makes me think of another minor issue... given that the 
> adaptorName is specified in the model, should there not be a place or 
> hook to specify any adaptor/db-specific initialization sql/code?
>
> Or, stated differently, should not adaptorName be specified in the 
> config file, along with the connection dictionary? And, should not the 
> config file contain or point to sql or other code to be executed on 
> specific events, such as when db is created, when connection is 
> established, etc. This flexibility, while it may risk being abused 
> ;),  could avoid getting stuck by the frameworks limitations at any 
> given moment....
>
> mario
>
>
>

[Fwd: Re: [Modeling-users] Optimistic Locking]

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

A message I sent incorrectly to the private mbox of Sébastian.



-------- Mensaje Original --------
Asunto: 	Re: [Modeling-users] Optimistic Locking
Fecha: 	Thu, 24 Jun 2004 11:25:15 +0200
De: 	Ernesto Revilla <er...@si...>
Para: 	Sebastien Bigaret <sbi...@us...>
Referencias: 	<40D...@si...> 
<87u...@me...>



Thanx a lot for your comments. (Perhaps some sentences could go into the 
documentation?)

The first thing: is there an easy way to use all attributes of an object 
for optimistic locking?

On the other hand, how can I easily simulate optimistic locking 
collisions within the same process? (suppose you use ZOPE which has just 
one process, but different EditingContext, and want the user to be 
warned, when data has been updated by another user?)

Erny

Sebastien Bigaret escribió:

>Ernesto Revilla <er...@si...> wrote:
>  
>
>>Dear Sébastien,
>>
>>could you explain in some words, and with one example how Optimistic Locking
>>should work?
>>    
>>
>
>Yes ;)
>
>  
>
>>I saw your commits, but I thought optimistic locking would protect
>>automatically the whole object from being updated from another
>>computer. What does it mean an attribute is used for optimistic locking?
>>That the attribute is checked that it is not updated by another person or
>>that it is used to check if another person has changed the object?
>>    
>>
>
>Say you have obj O (a person) w/ attributes name, age and birthday.
>
>'name' and 'age' are made 'usedForLocking', birthday isn't.
>
>In a EC you fetch a person 'p', manipulate/update it, changing whatever
>attributes, than you save changes. At this point (at saveChanges()
>time), we make sure that the corresponding row has the same value for
>columns 'name' and 'age' (which are marked as 'usedForLocking') than the
>value it had *when the object was fetched*.
>
>  If values are the same, the updates succeeds, otherwise saveChanges()
>  fails.
>
>That's the core of it. Optimistic locking is called optimistic because
>it makes the assumptions that few conflicts will occur, so the checking
>is only made at the last moment --when saving.
>
>Now two remarks:
>
>- if the corresponding person's birthday has been changed in the db by
>  an external process, optimistic locking wont notice because the
>  attribute wasn't used for locking,
>
>- within a single *process*, two ECs will never conflict. This is not
>  directly related to the way optimistic locking works, rather to the
>  way the framework handles those updates. When an EC saves its changes,
>  it broadcasts them to others. Default behaviour will be: when an ec
>  receives an update for an object, it applies these updates, then
>  applies back the changes that were made before within this ec.
>
>  Example:
>    # NB: p1=p2=Person(name='Cleese', age=42, birthday=None)
>    p1=ec1.fetch(...)
>    p2=ec2.fetch(...)  # p1, p2 correspond to the same rows
>    
>    p1.name='John Cleese'
>    p1.age=24
>    
>    p2.age=12
>    
>    ec1.saveChanges()
>    # now p2.name=='John Cleese', and p2.age==12
>
>  Of course you'll have delegates at hand to implement your own
>  behaviour to handle these cases.
>
>Hopefully this makes things clearer. If not, yell at me ;)
>
>
>-- Sébastien.
>
>
>  
>

Re: [Modeling-users] SQLite inserts slow

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

>   While we're at it, are there other PRAGMAs that you all using
>   sqlite think they should be controlled in the same way?

I have not played with sqlite pragmas, so none that I can think of. 
But, this makes me think of another minor issue... given that the 
adaptorName is specified in the model, should there not be a place or 
hook to specify any adaptor/db-specific initialization sql/code?

Or, stated differently, should not adaptorName be specified in the 
config file, along with the connection dictionary? And, should not the 
config file contain or point to sql or other code to be executed on 
specific events, such as when db is created, when connection is 
established, etc. This flexibility, while it may risk being abused ;),  
could avoid getting stuck by the frameworks limitations at any given 
moment....

mario

Re: [Modeling-users] SQLite inserts slow

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

Hi,

I don't know, but I think this is not needed. Just a little comment in 
the documentation should be enough, because changing the
* *default_synchronous * *setting with PRAGMA is permament setting. Of 
course, if you have to rebuild the database hundreds of times, this 
would be a nive feature.

Anyway, perhaps it would be a nice thing to have the possibility to do 
initialization for each connection. For postgresql and others it can be 
used to set the isolation level,  any encoding or language parameters, 
query modes, etc.

Regards,
Erny



Sebastien Bigaret escribió:

>Ok fine, and indeed, I've just read the documentation
>  http://www.hwaci.com/sw/sqlite/lang.html#pragma
>and this definitely seems to be far less dangerous than what I thought it
>could be.
>
>Do you think this could be useful enough to have a setting to control that
>within the framework? For example we could have a env.variable
>'SQLITE_SYNCHRONOUS_MODE' set to either 'NORMAL' (default), 'FULL' or 'OFF',
>an env.var. that the framework could use to set the synchr.mode when opening a
>connection.
>
>  While we're at it, are there other PRAGMAs that you all using
>  sqlite think they should be controlled in the same way?
>
>-- Sébastien.
>
>
>Ernesto Revilla <er...@si...> wrote:
>  
>
>>Hi again,
>>
>>Sebastien Bigaret escribió:
>>
>>    
>>
>>>>Interesting enough that the following instruction makes it much faster
>>>>causing SQLite to turn off disk sync:
>>>>*PRAGMA default_synchronous = OFF;
>>>>
>>>>        
>>>>
>>>Yes, but this makes the sqlite-db file very fragile, I believe this can
>>>completely waste your data when some errors happen, or am I wrong? (no
>>>time to check that in details right now)
>>>
>>>
>>>      
>>>
>>It depends. sqlite writes all changes to a journal file, and when commiting
>>processes the journal file and appends the results to the end of the
>>file. The fragile point is after the journal file has been processed, bu
>>before the data has been written to disk. Of course, this makes it more
>>fragile, but the probability of a system crash is not very high, provided we
>>are using powersupplies and stable OS. If we have a patch for this issue,
>>I'll turn on syncing again.
>>
>>With best regards,
>>Erny
>>    
>>
>
>
>  
>

Re: [Modeling-users] using Modeling w/o primary keys

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

        Hi Duncan,

  Fine, it seems this could make it for that appication(s) you were
  talking about. We'll probably get more info& questions soon ;)

In the meantime let's answer your question, you asked:
> I don't know if any of the client tables have multiple columns that define
> PKs, however, I just did a search on the mail list and saw this:
> http://sourceforge.net/mailarchive/message.php?msg_id=3D6801413
> Has there been any move to support multi-column PKs since then?

We've not moved an inch since then; as I usually say, I now do not have
the time to develop things if this is not at least a user's request,
just because I think features needs to get real-life testing to become
quickly mature and robust. And even then (when people need the feature)
it can sometimes take quite some time to implement --optimistic locking
is a good example.

  So, again, if you have the need for the feature and at least a "test"
  application ("test": from the framework's point of view :) then tell
  us and we'll probably make a step forward!!

Now, to be completely honest, having "raw" support for compound PK
should not be a real problem, however for now I cannot foresee how much
we could get in trouble wrt relationships based on compound PKs. But
since you said that your own needs by now won't use relationships, then
you can be optimistic if this is a feature you definitely need!

-- S=E9bastien.

Re: [Modeling-users] SQLite inserts slow

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

Ok fine, and indeed, I've just read the documentation
  http://www.hwaci.com/sw/sqlite/lang.html#pragma
and this definitely seems to be far less dangerous than what I thought it
could be.

Do you think this could be useful enough to have a setting to control that
within the framework? For example we could have a env.variable
'SQLITE_SYNCHRONOUS_MODE' set to either 'NORMAL' (default), 'FULL' or 'OFF',
an env.var. that the framework could use to set the synchr.mode when openin=
g a
connection.

  While we're at it, are there other PRAGMAs that you all using
  sqlite think they should be controlled in the same way?

-- S=E9bastien.


Ernesto Revilla <er...@si...> wrote:
> Hi again,
>=20
> Sebastien Bigaret escribi=F3:
>=20
> >>Interesting enough that the following instruction makes it much faster
> >>causing SQLite to turn off disk sync:
> >>*PRAGMA default_synchronous =3D OFF;
> >>
> >
> >Yes, but this makes the sqlite-db file very fragile, I believe this can
> >completely waste your data when some errors happen, or am I wrong? (no
> >time to check that in details right now)
> >
> >
> It depends. sqlite writes all changes to a journal file, and when commiti=
ng
> processes the journal file and appends the results to the end of the
> file. The fragile point is after the journal file has been processed, bu
> before the data has been written to disk. Of course, this makes it more
> fragile, but the probability of a system crash is not very high, provided=
 we
> are using powersupplies and stable OS. If we have a patch for this issue,
> I'll turn on syncing again.
>=20
> With best regards,
> Erny

Re: [Modeling-users] using Modeling w/o primary keys

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

On Jun 28, 2004, at 12:44 PM, Sebastien Bigaret wrote:

>
>   Hi Duncan,
>
> Does this mean that you need to access an already existing database 
> where *no*
> primary key are defined???

Most of their tables do, but some don't. The ones that don't may just 
be lookup tables, in which case there's no need to model them... The 
project has been a "black box": they want a generalized wrapper for 
some of their custom utilities, so os tools, and Modeling. I've been 
getting more info from them, though...

> PKs are important, yes, just because you need a PK to map an object w/ 
> its
> corresponding row in the database (even if you do not have a single
> relationship defined in the schema). Any objkect-relational mapper 
> will need a
> way to uniquely identify a row/an object (it does not mean, however, 
> that there
> should be an attribute explictely marked as the PK in the db, only 
> there is
> exists a set of attributes (generally one) that can be taken as the 
> PK).

Yes, as you can see, not only does what you say make perfect sense, but 
I am rather ignorant of database modeling below anything other than a 
purely superficial level.

> I bet you have PK defined in your tables, or am I wrong?

I don't have access to their databases, but have the understanding that 
most of them do, but some don't. Based on what you said above, I think 
it's perfectly acceptable to perform a PK check during metadata 
extraction, and throw an exception for any table without a PK.

> Secondly, could you
> tell whether you wish read-only access to the db? (I suspect you do, 
> but better
> be sure).

You would think, based on my initial question, that it would be 
read-only. If I have known what I was talking about, I would not have 
asked the question... your answer and questions are very instructive: I 
see now that in order for object mappers to be able to manipulate and 
save data back to the database, there must be primary keys (or some 
means of object identification).

Given that, I will write the code necessary to extract PK info from db 
metadata tables (postgres and oracle), and use that to create a db 
model. I'll give that a try and see how it works.

I don't know if any of the client tables have multiple columns that 
define PKs, however, I just did a search on the mail list and saw this:
http://sourceforge.net/mailarchive/message.php?msg_id=6801413
Has there been any move to support multi-column PKs since then?

Thanks for your patience and help!

Duncan

Re: [Modeling-users] using Modeling w/o primary keys

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

  Hi Duncan,

Does this mean that you need to access an already existing database where *no*
primary key are defined???

PKs are important, yes, just because you need a PK to map an object w/ its
corresponding row in the database (even if you do not have a single
relationship defined in the schema). Any objkect-relational mapper will need a
way to uniquely identify a row/an object (it does not mean, however, that there
should be an attribute explictely marked as the PK in the db, only there is
exists a set of attributes (generally one) that can be taken as the PK).

I bet you have PK defined in your tables, or am I wrong? Secondly, could you
tell whether you wish read-only access to the db? (I suspect you do, but better
be sure).

-- Sébastien.


Duncan McGreggor <py...@ad...> wrote:
> Hey folks,
> 
> I've got kind of an insane question... insane because Modeling is so 
> good, and I have a need to use it in a very limited fashion.
> 
> One of my clients wants to rollout support for Modeling in their python 
> applications, but wants to do it without support for primary keys. The 
> reason for this is that they are pulling meta-data out of databases 
> (i.e., basic column definitions for tables) but not anything regarding 
> relationships. They want to create attributes/properties of entities 
> based on this, and then use these models to programmatically manipulate 
> live data in the database.
> 
> Is using Modeling w/o support for primary keys possible? I have been 
> trying to do something like this, but it violates rules for valid 
> models in Modeling, and as such, it won't create any .py package model 
> files. My attempts at tweaking the code to disable support for PKs have 
> been catastrophic, as it seems it is woven into the very fabric of the 
> software. Is there a crazy hack I can use until the client is ready to 
> support primary keys in the meta-data extraction process?
> 
> Thanks for any help or advice!
> 
> Duncan

Re: [Modeling-users] quoting entity and attribute names

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

    Hi John,

  Since it is needed *now* then go for it :)

Put differently, this means: I'm sorry, but I won't have the time to look at
this tonite, so just make it the way you feel it should be done, and then I'll
argue if I think it needs to be discussed !-)

-- Sébastien.

John Lenton <jo...@vi...>:

> Sender: John Lenton <jo...@ma...>
> 
> On Wed, Jun 23, 2004 at 07:54:02PM +0200, Sebastien Bigaret wrote:
> > 
> > John Lenton <jo...@vi...> wrote:
> > > In a project I'm currently working on there is a class that we'd like
> > > to call "User", but we can't call it that and use Modeling in its
> > > current state: it's not quoting the names of entities (nor
> > > attributes), and user is a reserved word.
> > > 
> > > I looked into it, and I actually got it working, but I then saw that
> > > in SQLExpression there's a method `externalNameQuoteCharacter'; is the
> > > purpose of this method to be used (something like) this:
> > > 
> > >     [ in _addTableJoinsForAlias ]
> > > 
> > >     quoteChar = self.externalNameQuoteCharacter()
> > >     str += quoteChar + self._internals.entityExternalNameForAlias(alias)
> + quoteChar + ' ' + alias
> > > 
> > > ?
> > 
> > And to answer this very precisely, I do not feel really comfortable with
> > quoting external names when unneeded; the quoting should IMHO be done
> > only when a whole SQL statement is returned, not during intermediate
> > steps. This makes assembleDelete|Select|UpdateStatement() methods good
> > candidates, doesn't it?
> 
> agreed on the first point, but not on the second: assembleFoo takes a
> 'tableList' parameter that is already a (list of) table name(s). For
> the singular case this wouldn't be a problem, but in the case of
> select at least it very much is (IMVHO). I think the place to do this
> would be, for table names, tableListWithRootEntity (possibly via a
> 'quoted' parameter?); however, this implies that
> _addTableJoinsForAlias must behave similarly. For attribute names it
> seems the functionality should be in sqlStringForAttribute, but that
> might be too generic.
> 
> comments? I'm moving ahead with this implementation, but I understand
> it might have to be redone in some other way (time presses *now* :) )
> 
> -- 
> John Lenton (jo...@vi...) -- Random fortune:
> A vacuum is a hell of a lot better than some of the stuff that nature
> replaces it with.
> 		-- Tennessee Williams
> 

Re: [Modeling-users] quoting entity and attribute names

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

Sender: John Lenton <jo...@ma...>

On Wed, Jun 23, 2004 at 07:54:02PM +0200, Sebastien Bigaret wrote:
> 
> John Lenton <jo...@vi...> wrote:
> > In a project I'm currently working on there is a class that we'd like
> > to call "User", but we can't call it that and use Modeling in its
> > current state: it's not quoting the names of entities (nor
> > attributes), and user is a reserved word.
> > 
> > I looked into it, and I actually got it working, but I then saw that
> > in SQLExpression there's a method `externalNameQuoteCharacter'; is the
> > purpose of this method to be used (something like) this:
> > 
> >     [ in _addTableJoinsForAlias ]
> > 
> >     quoteChar = self.externalNameQuoteCharacter()
> >     str += quoteChar + self._internals.entityExternalNameForAlias(alias) + quoteChar + ' ' + alias
> > 
> > ?
> 
> And to answer this very precisely, I do not feel really comfortable with
> quoting external names when unneeded; the quoting should IMHO be done
> only when a whole SQL statement is returned, not during intermediate
> steps. This makes assembleDelete|Select|UpdateStatement() methods good
> candidates, doesn't it?

agreed on the first point, but not on the second: assembleFoo takes a
'tableList' parameter that is already a (list of) table name(s). For
the singular case this wouldn't be a problem, but in the case of
select at least it very much is (IMVHO). I think the place to do this
would be, for table names, tableListWithRootEntity (possibly via a
'quoted' parameter?); however, this implies that
_addTableJoinsForAlias must behave similarly. For attribute names it
seems the functionality should be in sqlStringForAttribute, but that
might be too generic.

comments? I'm moving ahead with this implementation, but I understand
it might have to be redone in some other way (time presses *now* :) )

-- 
John Lenton (jo...@vi...) -- Random fortune:
A vacuum is a hell of a lot better than some of the stuff that nature
replaces it with.
		-- Tennessee Williams

[Modeling-users] using Modeling w/o primary keys

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

Hey folks,

I've got kind of an insane question... insane because Modeling is so 
good, and I have a need to use it in a very limited fashion.

One of my clients wants to rollout support for Modeling in their python 
applications, but wants to do it without support for primary keys. The 
reason for this is that they are pulling meta-data out of databases 
(i.e., basic column definitions for tables) but not anything regarding 
relationships. They want to create attributes/properties of entities 
based on this, and then use these models to programmatically manipulate 
live data in the database.

Is using Modeling w/o support for primary keys possible? I have been 
trying to do something like this, but it violates rules for valid 
models in Modeling, and as such, it won't create any .py package model 
files. My attempts at tweaking the code to disable support for PKs have 
been catastrophic, as it seems it is woven into the very fabric of the 
software. Is there a crazy hack I can use until the client is ready to 
support primary keys in the meta-data extraction process?

Thanks for any help or advice!

Duncan

Re: [Modeling-users] Bug report with dynamic

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

    Hi Erny,

  Thanks for reporting, the pb. here is that build() does
not accept a PyModel yet. This should be fixed!! Could you please fill a bug
report? Thanks.

  Now in the meantime you can have it work this way:

>>> from Modeling.PyModel import Model, Entity, AString
>>> from Modeling import dynamic
>>> m=Model("TheModel")  # a PyModel.Model
>>> m.version='0.1'  # This is mandatory!!
>>> e=Entity("Person",properties=[AString("name")])
>>> m.entities.append(e)
>>> m.build() # Builds a Model.Model and stores it in 'component'
>>> model=m.component # get the corresponding Model.Model
>>> dynamic.build(model)
>>> import TheModel
>>> TheModel
<module 'TheModel' (built-in)>
>>> from TheModel import Person
>>> Person
<module 'TheModel.Person' (built-in)>
>>> from TheModel.Person import Person
>>> Person
<class 'TheModel.Person.Person'>


...given that you apply the included patch ;) which fixes the incorrect way the
modules and classes where represented (as string)

(I'll integrate this into the CVS main trunk)

-- Sébastien.


----------------------------------------------------------
Index: Modeling/dynamic.py
===================================================================
RCS file: /cvsroot/modeling/ProjectModeling/Modeling/dynamic.py,v
retrieving revision 1.1
diff -u -r1.1 dynamic.py
--- Modeling/dynamic.py 16 Feb 2004 20:01:06 -0000      1.1
+++ Modeling/dynamic.py 25 Jun 2004 16:02:03 -0000
@@ -159,14 +159,14 @@
     setattr(m, e.name(),c)
     classes[e.name()]=c
     modules[e.name()]=m
-    m.__name__='AB.'+e.name() # Not required? but in accordance to
observations
+    m.__name__= module_name+'.'+e.name()
     add_init(c, e)
     add_entityName(c, e)
     add_getters(c, e)
     add_setters(c, e)
     if define_properties:
       add_properties(c, e)
-  
+    c.__module__=module_name+'.'+e.name()
   
   p=new.module(module_name)
   #m.Book=classes['Book']

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




Ernesto Revilla <er...@si...> wrote:
> Dear Sébastien,
> 
> going through dynamic, I'm really impressed. (I can learn a lot of stuff 
> from you). Although I still did no tests, here what seems a bug to me:
> 
> When I do the following, I get an error (CVS version):
> 
>  >>> from Modeling.PyModel import Model, Entity, AString
>  >>> from Modeling import dynamic
>  >>> m=Model("TheModel")
>  >>> e=Entity("Person",properties=[AString("name")]
>  >>> m.entities.append(e)
>  >>> dynamic.build(m)
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
>   File "C:\prg\python23\Lib\site-packages\Modeling\dynamic.py", line 
> 153, in build
>     module_name=model.packageName()
> TypeError: 'str' object is not callable
> 
> May be this is not  a bug? The: m=Model("TheModel")   should create an 
> empty model.
> 
> With regards,
> Erny
> 
> 
> 
> 
> 

Re: [Modeling-users] Bug report with dynamic

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

In PyModel, line 971:  v=apply(v.method, l), the function is evaluated 
and substituted by it's value, so:
<function identity at 0x00FD2C70>('name',)  will turn into
'TheModel' and this will be stored in object, so packageName is not a 
function anymore.

Erny

Ernesto Revilla escribió:

> Dear Sébastien,
>
> going through dynamic, I'm really impressed. (I can learn a lot of 
> stuff from you). Although I still did no tests, here what seems a bug 
> to me:
>
> When I do the following, I get an error (CVS version):
>
> >>> from Modeling.PyModel import Model, Entity, AString
> >>> from Modeling import dynamic
> >>> m=Model("TheModel")
> >>> e=Entity("Person",properties=[AString("name")]
> >>> m.entities.append(e)
> >>> dynamic.build(m)
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
>   File "C:\prg\python23\Lib\site-packages\Modeling\dynamic.py", line 
> 153, in build
>     module_name=model.packageName()
> TypeError: 'str' object is not callable
>
> May be this is not  a bug? The: m=Model("TheModel")   should create an 
> empty model.
>
> With regards,
> Erny
>
>
>
>

[Modeling-users] Bug report with dynamic

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

Dear Sébastien,

going through dynamic, I'm really impressed. (I can learn a lot of stuff 
from you). Although I still did no tests, here what seems a bug to me:

When I do the following, I get an error (CVS version):

 >>> from Modeling.PyModel import Model, Entity, AString
 >>> from Modeling import dynamic
 >>> m=Model("TheModel")
 >>> e=Entity("Person",properties=[AString("name")]
 >>> m.entities.append(e)
 >>> dynamic.build(m)
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "C:\prg\python23\Lib\site-packages\Modeling\dynamic.py", line 
153, in build
    module_name=model.packageName()
TypeError: 'str' object is not callable

May be this is not  a bug? The: m=Model("TheModel")   should create an 
empty model.

With regards,
Erny