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

Re: [Modeling-users] debianized modeling

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

        Hi,

  Hey! This is very interesting ; I've downloaded the files and I'll
have a look at them in the next coming days. I'll probably have a look
to the debian howtos as well, it's something I plan to do for such a
loooong time ;)

  The pb. with binaries conflicting in /usr/bin could be annoying,
  sometimes you really need different python versions installed at the
  same time, but we'll see, there must be solutions.

Would you possibly consider maintaining these files if we integrate this
in CVS and use them to distribute debian packages as well?

        Thanks a lot for sharing,

-- S=E9bastien.


Guenther Starnberger <gs...@sy...> wrote:
> hello,
>=20
> i created notificationframework & modelingcore (& cheetahtemplate) debian=
=20
> packages for my private use and thought that you may be interested in=20
> including the required changes into the main distribution. (the only chan=
ge=20
> would be a new subdirectory (including some files) called 'debian' which=
=20
> gives debian users the possibility to automatically create binary package=
s by=20
> calling the 'dpkg-buildpackage' command).
>=20
> i'm not a debian developer nor did i create any debian packages before, s=
o=20
> it's possible that there are some bugs, etc. - it works well on my system.
> the only small problem i noticed is that the modelingcore packages for
> different python versions conflict, because they share the same files in
> /usr/bin/ (e.g. 'mdl_generate_python_code.py'). (the cheetahtemplate pack=
ages=20
> currently have the same problem.)
>=20
> the required files are available at http://s2.enemy.org/~gst/misc/ - to c=
reate=20
> debian packages the 'debian' directory has to be moved into the root=20
> directory of the respective source distribution.
>=20
> binary packages are created for following python versions: 2.1, 2.2, 2.3
> i only tested it on debian testing/unstable. to create debian woody packa=
ges
> the only required change should be to disable the creation of a binary
> package for python 2.3.
>=20
> (because the python-modelingcore package depends on python-cheetahtemplat=
e, i=20
> mailed the cheetahtemplate people too about a debianized version of=20
> cheetahtemplate.)
>=20
> cu
> /gst

[Modeling-users] debianized modeling

[Guenther S. <gs...@sy...>]

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

hello,

i created notificationframework & modelingcore (& cheetahtemplate) debian=20
packages for my private use and thought that you may be interested in=20
including the required changes into the main distribution. (the only change=
=20
would be a new subdirectory (including some files) called 'debian' which=20
gives debian users the possibility to automatically create binary packages =
by=20
calling the 'dpkg-buildpackage' command).

i'm not a debian developer nor did i create any debian packages before, so=
=20
it's possible that there are some bugs, etc. - it works well on my system.
the only small problem i noticed is that the modelingcore packages for
different python versions conflict, because they share the same files in
/usr/bin/ (e.g. 'mdl_generate_python_code.py'). (the cheetahtemplate packag=
es=20
currently have the same problem.)

the required files are available at http://s2.enemy.org/~gst/misc/ - to cre=
ate=20
debian packages the 'debian' directory has to be moved into the root=20
directory of the respective source distribution.

binary packages are created for following python versions: 2.1, 2.2, 2.3
i only tested it on debian testing/unstable. to create debian woody packages
the only required change should be to disable the creation of a binary
package for python 2.3.

(because the python-modelingcore package depends on python-cheetahtemplate,=
 i=20
mailed the cheetahtemplate people too about a debianized version of=20
cheetahtemplate.)

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

iD8DBQE/U0+RZtF7I/+gjcERAruYAJ0ZZcDZlFSmO9RPqp0cx6E0YZlemwCfb3+J
1TJwNvjvMMlLL9o8P6VY1D4=3D
=3DI0bE
=2D----END PGP SIGNATURE-----

Re: [Modeling-users] EditingContext and Zope Sessions

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

        Hi,

frobni barka <fro...@ya...> wrote:
> Hello,
>=20
> According to the documentation
> ZEditingContextSessioning allows to lazily create an
> EditingContext on a per-session basis.
>=20
> Is it possible to somehow (automatically) bind the
> EditingContext to a Zope Transaction (e.g. a Web
> Request).

Yes it is --see below.

> What is the advantage of binding the EditingContext to
> a Session instead of a transaction? - e.g. Zope SQL
> Methods commit the (SQL) Transaction on the end of the
> Zope Transaction and I never had any problems with
> them.

  The EC is delivered as part of the session. This allows you to decide
  where you want to save the changes. This may --or may not-- be at the
  end of a zope transaction. A typical situation where both are
  decorrelated is when you needs two (html/zope) pages or more to make
  changes.=20

With an example this is clearer: suppose you have an address book
application, and that Persons objects must have an valid Address (i.e.
the relationship between Person and Address is mandatory). Suppose now
that you want to have one page for filling the person's properties
(first & last name, etc.), then a second one to fill his/her address
fields.

  Page 1: Person -> validate -> Page 2: Address -> validate -> save changes

Here you don't want to save your changes when page 1 validates its
changes (this is the end of a zope transaction), but after page 2
validates. Hence, in this case, you'll design your product to
saveChanges() when page 2 is validated. Moreover, if you send a
saveChanges() when page 1 validates, you'll get an error, because the
person inserted in the EC has no address while this is required by the
model: the EC won't let you save objects in an inconsistent state.

  Back to your problem now: what you're asking for is not in-the-box,
  because I never needed it :) I've quickly made a patch that you'll
  find at the end of the message, which enables automatic saveChanges().

Apply it to ZEditingContextSessioning/__init__.py

   patch -p0 < __init__.py.patch

and then all your SESSION.defaultEditingContext() will saveChanges()
when a zope transaction ends (just like ZSQL methods do).

  I'd be glad to hear from you if you use it successfully --I'll then
  probably add this as an option in the product itself.

        Regards,

-- S=E9bastien.


Here is the patch __init__.py.patch:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/modeling/ZModeling/ZEditingContextSessioning/__init__.py=
,v
retrieving revision 1.3
diff -u -r1.3 __init__.py
--- __init__.py 22 Apr 2003 09:36:50 -0000      1.3
+++ __init__.py 31 Aug 2003 22:52:33 -0000
@@ -36,6 +36,31 @@
 from Products.Transience.TransientObject import TransientObject
 import zLOG
=20
+from Shared.DC.ZRDB.TM import TM
+class ECProxy(TM):
+  def __init__(self, ec):
+    zLOG.LOG("ECProxy", zLOG.INFO, '__init__')
+    self.ec=3Dec
+    self._register()
+=20=20=20=20
+  def _abort(self):
+    zLOG.LOG("ECProxy", zLOG.INFO, '_abort')
+    pass
+
+  def _finish(self):
+    zLOG.LOG("ECProxy", zLOG.INFO, '_finish')
+    self.ec.saveChanges()
+
+  def _begin(self):
+    zLOG.LOG("ECProxy", zLOG.INFO, '_begin')
+    pass
+
+  def __getattr__(self, n):
+    zLOG.LOG("ECProxy", zLOG.INFO, "__getattr__")
+    if hasattr(self.ec, n):
+      return getattr(self.ec, n)
+    raise ValueError
+=20=20
 ## Implementation note:
 ## session.token was formerly used instead of session.id
 ## --> BAD IDEA
@@ -64,7 +89,8 @@
   """
   Returns the EditingContext bound to 'session'
   """
-  return EditingContextSessioning.getEditingContext(session.id)
+  zLOG.LOG("Products.ZEditingContextSessioning", zLOG.DEBUG, 'defaultEC()')
+  return ECProxy(EditingContextSessioning.getEditingContext(session.id))
=20
=20
 def initialize(context):

[Modeling-users] EditingContext and Zope Sessions

[frobni b. <fro...@ya...>]

Hello,

According to the documentation
ZEditingContextSessioning allows to lazily create an
EditingContext on a per-session basis.

Is it possible to somehow (automatically) bind the
EditingContext to a Zope Transaction (e.g. a Web
Request).

What is the advantage of binding the EditingContext to
a Session instead of a transaction? - e.g. Zope SQL
Methods commit the (SQL) Transaction on the end of the
Zope Transaction and I never had any problems with
them.

thanx


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [Modeling-users] Release 0.9pre14 is out: Oracle supported!

[Jerome K. <Jer...@fi...>]

Sebastien Bigaret wrote:

>  I've also added a "quick example" page which now opens as the first pa=
ge
>  at modeling.sourceforge.net
>  (or at http://modeling.sf.net/quick_overview.html).
>
>
>  This was requested for a long-time (and so was the INSTALL file added
>in the last release:). If you have better ideas, or if you think this
>could be presented in a different manner, please share your critics!
>
> =20
>

Lo Mr Big .. juste une petite remarque .. peut tu passer un
coup de code2html sur les exemples avant de les inclure
sur la page d'overview ? . Si joint un exemple de resultat

C quand m=EAme bcp + lisible :)


Alors ta commenc=E9 =E0 l'enst ? on s'est pas encore crois=E9
.. je sais que tu boude le RAK mais quand m=EAme


A ++

Re: [Modeling-users] Release 0.9pre14 is out: Oracle supported!

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

  I've also added a "quick example" page which now opens as the first page
  at modeling.sourceforge.net
  (or at http://modeling.sf.net/quick_overview.html).


  This was requested for a long-time (and so was the INSTALL file added
in the last release:). If you have better ideas, or if you think this
could be presented in a different manner, please share your critics!

        Regards,

-- S=E9bastien.

[Modeling-users] Release 0.9pre14 is out: Oracle supported!

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

        Hi all,

  I'm pleased to announce that 0.9pre14 is out. The major enhancement is
the full support for Oracle database servers, both Oracle 8i and 9i.

I also worked on the documentation:

* the two parts: what a entity-relation model is and what are its
  properties on one hand, the formats in which they are stored on
  the other hand, are now completely separated in the Users's Guide.
  Additionally, documentation for PyModels has been written. It is
  not finished yet, but hopefully you'll find there any relevant
  informations.

    Description of E-R models:
         http://modeling.sourceforge.net/UserGuide/model-concepts.html
     and http://modeling.sourceforge.net/UserGuide/model-details.html

    Doc. for PyModels:
         http://modeling.sourceforge.net/UserGuide/pymodel.html

    Doc. for XML-models:
         http://modeling.sourceforge.net/UserGuide/model-xml-format.html

* A dedicated section has been added to document how to model and handle
  many-to-many relationships. See:=20
  http://modeling.sourceforge.net/UserGuide/design-rels-many-to-many.html

  We've already discussed this on the mailing-list, and I'd like to
  thank Mario for its contributions and for testing sample codes (all
  errors are mine, however ;).

        Best regards,

-- S=E9bastien.


------------------------------------------------------------------------
0.9-pre-14 (2003/08/31)
-----------------------

  * Documentation:

      - documentation for models in general has been rewritten. In particul=
ar,
        PyModels are now fully documented

      - instructions for modeling and manipulating many-to-many relationshi=
ps
        have been added in the User's Guide.

  * PyModel.Model:
=20=20=20=20
    - Fixed bug #795561: __init__() did not recognize 'version' as a parame=
ter

    - Fixed bug #794185: Entity.__init__() ignores associations

    - Now raises PyModel.IncompatibleVersionError when a model has an
      incompatible version (was: ValueError)

  * Fix for bug #785432 included in the previous release was misplaced and
    inactive. Fixed.

  * SQLExpression: added support for joinClauseString(), which offers an
    alternative when the underlying db-server does not support SQL JOIN
    statement.

  * Full support for Oracle database: added OracleAdaptorLayer (do not use
    now, there are still commits). Test units updated.

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

Re: [Modeling-users] few misc issues with sqlite adaptor

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

On Samedi, ao=FB 9, 2003, at 13:49, Sebastien Bigaret wrote:
> Mario Ruggier <ma...@ru...> wrote:
>> On Jeudi, ao=FB 7, 2003, at 23:41, Sebastien Bigaret wrote:
>>> Mario Ruggier <ma...@ru...> wrote:
>>>> a few points, encountered when trying to make a pymodel,
>>>> running the mdl_* scripts, and using SQLite adaptor:
>>>>
>>>> 1. when running mdl_validate_model on a pymodel that
>>>> does not hard-wire an adaptorname:
>>>>
>>>>   * Warning(s):
>>>>     - Can't find concrete adaptor: can't check SQL types
>>>
>>> True, when it cannot be found they cannot be checked, so we warn the
>>> user.
>>
>> The point I was hinting ;) at is that in this case shouldn't =20
>> mdl_validate
>> select the adaptor pointed to by the "foremost" cfg file?
>
> I don't think I will support this. The connection dictionaries can be
> supplied within a model and/or in a file pointed by environment =20
> variable
> MDL_DB_CONNECTIONS_CFG. I think this is enough, and that this scheme
> shouldn't be complicated.

OK. Simplicity is always good.
Not to inadvertently use a central cfg for testing, I have a wrapper =20
for the mdl_*
scripts that always sets this variable to point to a specified =20
(defaults to samedir)
cfg.

[...]

>>>> 3. When running mdl_* utility scripts, the main cfg (pointed to by =20=

>>>> env
>>>> var MDL_DB_CONNECTIONS_CFG) is not taken into account.
>>>> Same goes for when an Adaptorname.cfg is made available in the
>>>> same directory as the pymodel.
>>>
>>> True, no matter where a .cfg is, if it's pointed to by =20
>>> MDL_DB_CONNECTIONS_CFG
>>> it should taken into account. This is a bug.
>>
>> Ehm, on closer looks I would have to take this back.
>> Generate_db does take this into account. Validate does
>> not... I have not determined of all the cases when it does or
>> does not though... I will file as "mdl_* scripts do not always take =20=

>> .cfg into
>> account",
>> or 785436.
>
> I'm sorry, I tried but cannot reproduce the bug here, I need more =
info.

Well, it is not clear to me:
- what may be in the cfg
- what should be in the cfg
- what may be in the command-line --admin-dsn
- what should be in the commandline --admin-dsn
- what optionally may be specified in the connectionDictionary in the =20=

model
Plus, if something is specified in more than one place which one takes =20=

precedence?

More precisely, here is a problem: if i do not specify the database in =20=

the
connDict of the model (I want to take out the connection dictionary =20
from the model,
in my opinion it is not where it should be), but do specify the db on =20=

the command
line with --admin-dsn, then mdl_gen_DB gives an error:

[0.9pre13]
% mdl_generate_DB_schema.py -C --admin-dsn localhost:db_m2m:dummy:dummy =20=

pym_m2m.py
Traceback (most recent call last):
   File "/usr/bin/mdl_generate_DB_schema.py", line 353, in ?
     status =3D main(sys.argv)
   File "/usr/bin/mdl_generate_DB_schema.py", line 340, in main
     dsn_db_name =3D model.connectionDictionary()['database']
KeyError: database

[0.9pre12]
% mdl_generate_DB_schema.py -C --admin-dsn localhost:db_m2m:dummy:dummy =20=

pym_m2m.py
Unable to open connexion w/ connectionDictionary=3D{'password': 'xxxx'}
Reason:
Traceback (most recent call last):
   File =20
"/usr/lib/python2.2/site-packages/Modeling/DatabaseAdaptors/=20
AbstractDBAPI2AdaptorLayer/AbstractDBAPI2AdaptorContext.py", line 219, =20=

in __openConnectionIfNecessary__
     self._adaptor.dbAPI_connectionDictionaryForConnect(cnxDict))
   File =20
"/usr/lib/python2.2/site-packages/Modeling/DatabaseAdaptors/=20
SQLiteAdaptorLayer/SQLiteAdaptor.py", line 102, in =20
dbAPI_connectionDictionaryForConnect
     return {'db': aModelConnectionDictionary['database']}
KeyError: database


Another problem: if i do not specify an adaptor in the pymodel, but i do
in the cfg pointed to by the environment, both mdl_validate and =20
mdl_generate_db
do not use the default adaptor specified in the cfg (tested with =20
0.9pre13).
Again, in my opinion such info should not be in the model -- a model, =20=

while
specifying db-specific things such as widths, and external types and so =20=

on,
should, in an ideal world, be able to be used with no modifications with
different SQL-respecting db servers. For example, I may want to develop
and test with sqlite, and then deploy on postrges, and it would be nice =20=

to
be able to do such things with no modifs on the models.


>> In addition to this problem, I feel it would be convenient (and safe) =
=20
>> to
>> make it such that either (a) commandline switch to specify a "test" =20=

>> cfg
>> whenever desired, and/or (b) use a local cfg if one is present (by =20=

>> which
>> name?).
>> This to prevent overwriting real db files while testing changed =20
>> models.
>
> I understand what you say, but as I said above I do not feel like
> complicating things here. It's impossible to foresee every possible
> situations where valuable data could be lost, and I have the feeling
> that trying to find more and more of these situations could lead to =
the
> wrong feeling that the script is safe, while complicating the =20
> everyday's
> life of developpers.
>
>   Right, mdl_generate_DB_schema.py should be handled with care, just
> like 'DROP' statements when connecting to a database, or shell's 'rm'
> when speaking of sqlite files... Does it make sense?

When I use rm I do not have a hidden value somewhere (env var that
points to another directory!) that underhandedly changes the obvious
face-value of the rm command being issued... so I am never surprised
at the results.

One may foresee an option to set which cfg file to use (but this is =20
easily
accomplished by a wrapper script that resets the envvar... so whether
this is warranted, not sure, your call).

The collection of mdl_* scripts sport an impressive variety of =20
options...
a another little one won't hurt surely ;-? (Hmmn, one should take a few
of the others out I think ;-!)

Thanks for all the other fixes, and the super-quick release afterwards!

Cheers, mario

[Modeling-users] Release 0.9-pre-13 is out

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

        Hi all,

  Release 0.9-pre-13 is out. It contains bug fixes we already discussed
  here these days, most of which addresses bugs in the generation of SQL
  statements.

  All database layers are concerned:

    - 'like' qualifiers are no longer case-insensitive w/ sqlite and
      mysql,

    - raw characters '_' and '%' are now correctly handled in 'like'
      qualifiers. Fixed layers: postgresql, sqlite


  Last, I'll be off from tuesday to the next monday, maybe with an
  intermittent but slow internet connection, so you should not expect a
  quick answer from me in this period.

        Best regards,

-- S=E9bastien.


------------------------------------------------------------------------
0.9-pre-13 (2003/08/10)
-----------------------

  * Added an installation guide

  * Fixed bug #785913: "LIKE qualifier w/ raw '%' and '_' characters does n=
ot
    work w/ SQLite"

  * Fixed bug #786217: 'Qualifier LIKE can be case-insensitive' (bug was
    observed for MySQL and SQLite)

  * Fixed: Postgresql Layer can now correctly handled raw '_' characters in=
 a
    LIKE statement

  * Fixed bug #785432: SQLite now accepts TEXT, and DATETIME, TEXT, NUMBER,
    DECIMAL, SMALLINT, REAL as well in addition to the sql types basically
    accepted by the core's SQLExpression (CHAR, FLOAT, INT, INTEGER, NUMERI=
C,
    DATE, TIME, TUMESTAMP and VARCHAR)

  * Fixed bug #785434: mdl_generate_DB_schema now detects when the database
    (file)name in dsn and in the admin-dsn are not the same.

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

Re: [Modeling-users] fetch qualifier problem

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

I wrote:
>   While making the test suite for all this and roaming around sqlite
> source code, I incidentally found an other bug
> https://sf.net/tracker/index.php?func=3Ddetail&aid=3D786217&group_id=3D58=
935&atid=3D489335
>       [ 786217 ] Qualifier LIKE can be case-insensitive
>=20
>   --> When using 'LIKE' in qualifier strings, the match for MySQL and
>   SQLite is case-*insensitive*. I did not noticed it, but the fact is
>   that sql 'LIKE' operator is by default case-insensitive for these two
>   databases.
>=20
> About SQLite: the fix for the above bug is expected to fix bug #785913:
> "LIKE qualifier w/ raw '%' and '_' does not work w/ SQLite" as well. Now
> for case insensitive match, sqlite lacks the ability to escape the
> special characters --I've submitted a patch to the sqlite ml today,
> we'll see what happens,
> cf. http://groups.yahoo.com/group/sqlite/message/4605

Both bugs have been fixed (for mysql and sqlite) and patches can be
found at:
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D786217&group_=
id=3D58935&atid=3D489335

  Note that the problem remains w/ sqlite and 'ilike', for the reason
  explained above.

Mario: your qualifiers with LIKE operators containing raw '%' or '_'
characters should now work as expected.

        Regards,

-- S=E9bastien.

Re: [Modeling-users] _sqlite.IntegrityError:PRIMARY KEY must be unique

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

On Dimanche, ao=FB 10, 2003, at 16:21, Sebastien Bigaret wrote:
>         Hi,
>
> Mario Ruggier <ma...@ru...> wrote:
>> I am getting this error (subject line) when I try to insert a new
>> object into a table. The PK in question is not a class property, and
>> I do not mess with it in any way. The situation is that I had a bunch
>> of rows already in this table, and dumped the sql for them to be
>> able to recreate them. I then recreated the sqlite db to reflect=20
>> changes
>> to the model, and i re-inserted the previously existing rows for the=20=

>> one
>> table (which is completely untouched by the model changes). Doing
>> a "select * from table" gives the rows correctly.
>>
>> However, since then, the primary key count for newly created objects
>> has restarted at 1, and each time i attempt to insert a new object,
>> he (the EC) increments this, but since there are already so many in=20=

>> the
>> db, the insertion fails with the above error.
>>
>> What's going on?
>
> The pk generation uses either a sequence or a specific table (sqlite
> uses a specific table, because it lacks support for sequences).
>
>   When restoring your db, you need to restore these tables and their
>   values as well.
>
> Say you have a table book, then the corresponding table for pk
> generation is: PK_SEQ_BOOK
>
>   You can update it by:
>
>   1. select max(id) from BOOK;
>
>   2. delete from PK_SEQ_BOOK;
>
>   3. insert into PK_SEQ_BOOK value(<n>);  --where <n> is the result of
>      step 1.
>
> Note that if you use inheritance, step 1. should be performed against
> all tables in the inheritance tree, and you'll use the maximum of =
these
> numbers in step 3. Last, the name of the table/sequence if always
> PK_SEQ_<name>, where name is in general the external name of the root
> entity (see Entity.primaryKeyRootName() and SQLiteAdaptorChannel's
> primaryKeysForNewRowsWithEntity()).
>
> Last note: when using a table for PK generation, it should have only=20=

> one
> row, this is why step 2. is there.

OK, thanks... I was overseeing the seq table.
Works perfectly now.

mario

> -- S=E9bastien.

Re: [Modeling-users] takeValue* vs. setValue*

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

On Dimanche, ao=FB 10, 2003, at 16:07, Sebastien Bigaret wrote:
> Mario Ruggier <ma...@ru...> wrote:
>> I get this warning:
>>
>> DeprecationWarning: Method setValueForKey is deprecated. Please use
>> takeValueForKey instead.
>>
>> I may have misundertood the discussion earlier, but my understanding
>> was that "setValue*" is what we agreed to standardize upon?
>
> Sorry, the discussion ended up with:
>
>   - cleaning KeyValueCoding,
>
>   - design an alternate mix-in class
>
> See in particular:
>     https://sourceforge.net/mailarchive/message.php?msg_id=3D5250043
>     https://sourceforge.net/mailarchive/message.php?msg_id=3D5420400
>   (last one is your post ;)

In which I actually said 'OK' to depracte setValue*... ;)
In my head I had it the opposite way! Sorry about that.

Anyway, we stick to what we have now.
About the continued discussion for a replacement of KVC + relation=20
manips,
as exposed by methods on CustomObject, I will let it simmer for a
while. Maybe in the meantime, an "API quick reference" page could
minimize all these issues, as well as help indicate what the API could=20=

be.
I will work on this.

Cheers, mario


>   Now if you feel like taking the lead for discussing this and=20
> ultimately come
>   w/ a proposal, feel free :)
>
>
> -- S=E9bastien.
>

Re: [Modeling-users] _sqlite.IntegrityError:PRIMARY KEY must be unique

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

        Hi,

Mario Ruggier <ma...@ru...> wrote:
> I am getting this error (subject line) when I try to insert a new
> object into a table. The PK in question is not a class property, and
> I do not mess with it in any way. The situation is that I had a bunch
> of rows already in this table, and dumped the sql for them to be
> able to recreate them. I then recreated the sqlite db to reflect changes
> to the model, and i re-inserted the previously existing rows for the one
> table (which is completely untouched by the model changes). Doing
> a "select * from table" gives the rows correctly.
>=20
> However, since then, the primary key count for newly created objects
> has restarted at 1, and each time i attempt to insert a new object,
> he (the EC) increments this, but since there are already so many in the
> db, the insertion fails with the above error.
>=20
> What's going on?

The pk generation uses either a sequence or a specific table (sqlite
uses a specific table, because it lacks support for sequences).

  When restoring your db, you need to restore these tables and their
  values as well.

Say you have a table book, then the corresponding table for pk
generation is: PK_SEQ_BOOK

  You can update it by:

  1. select max(id) from BOOK;

  2. delete from PK_SEQ_BOOK;

  3. insert into PK_SEQ_BOOK value(<n>);  --where <n> is the result of
     step 1.

Note that if you use inheritance, step 1. should be performed against
all tables in the inheritance tree, and you'll use the maximum of these
numbers in step 3. Last, the name of the table/sequence if always
PK_SEQ_<name>, where name is in general the external name of the root
entity (see Entity.primaryKeyRootName() and SQLiteAdaptorChannel's
primaryKeysForNewRowsWithEntity()).

Last note: when using a table for PK generation, it should have only one
row, this is why step 2. is there.

-- S=E9bastien.

Re: [Modeling-users] takeValue* vs. setValue*

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

Mario Ruggier <ma...@ru...> wrote:
> I get this warning:
>=20
> DeprecationWarning: Method setValueForKey is deprecated. Please use
> takeValueForKey instead.
>=20
> I may have misundertood the discussion earlier, but my understanding
> was that "setValue*" is what we agreed to standardize upon?

Sorry, the discussion ended up with:

  - cleaning KeyValueCoding,

  - design an alternate mix-in class

See in particular:
    https://sourceforge.net/mailarchive/message.php?msg_id=3D5250043
    https://sourceforge.net/mailarchive/message.php?msg_id=3D5420400
  (last one is your post ;)


  Now if you feel like taking the lead for discussing this and ultimately c=
ome
  w/ a proposal, feel free :)


-- S=E9bastien.

[Modeling-users] takeValue* vs. setValue*

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

Hi,

I get this warning:

DeprecationWarning: Method setValueForKey is deprecated. Please use 
takeValueForKey instead.

I may have misundertood the discussion earlier, but my understanding
was that "setValue*" is what we agreed to standardize upon?

mario

[Modeling-users] _sqlite.IntegrityError:PRIMARY KEY must be unique

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

Hi,

I am getting this error (subject line) when I try to insert a new
object into a table. The PK in question is not a class property, and
I do not mess with it in any way. The situation is that I had a bunch
of rows already in this table, and dumped the sql for them to be
able to recreate them. I then recreated the sqlite db to reflect changes
to the model, and i re-inserted the previously existing rows for the one
table (which is completely untouched by the model changes). Doing
a "select * from table" gives the rows correctly.

However, since then, the primary key count for newly created objects
has restarted at 1, and each time i attempt to insert a new object,
he (the EC) increments this, but since there are already so many in the
db, the insertion fails with the above error.

What's going on?

mario

Re: [Modeling-users] fetch qualifier problem

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

        Hi,

  While making the test suite for all this and roaming around sqlite
source code, I incidentally found an other bug
https://sf.net/tracker/index.php?func=3Ddetail&aid=3D786217&group_id=3D5893=
5&atid=3D489335
      [ 786217 ] Qualifier LIKE can be case-insensitive

  --> When using 'LIKE' in qualifier strings, the match for MySQL and
  SQLite is case-*insensitive*. I did not noticed it, but the fact is
  that sql 'LIKE' operator is by default case-insensitive for these two
  databases.

About SQLite: the fix for the above bug is expected to fix bug #785913:
"LIKE qualifier w/ raw '%' and '_' does not work w/ SQLite" as well. Now
for case insensitive match, sqlite lacks the ability to escape the
special characters --I've submitted a patch to the sqlite ml today,
we'll see what happens,
cf. http://groups.yahoo.com/group/sqlite/message/4605

-- S=E9bastien.


Sebastien Bigaret <sbi...@us...> writes:

> Mario Ruggier <ma...@ru...> writes:
>=20
> > Sorry, I did not mention that this was running on sqlite.
> > The problem here occurs for string values that contain '_'
> > (for '@'. it actually works fine, sorry had it wrong the first time).
>=20
> This is a problem w/ sqlite. The problem happens for '_' and '%', and I
> can't even find out to do this on the sqlite commandline. I've just sent
> the question to the sqlite ml, we'll see then.
>=20
> > Small question: when i try the aove from inside a py program
> > (a unittest testcase test), setting this envvar to 'YES', nothing happe=
ns...
> > or so it seems. Where should i go to get stderr (osx) ?
>=20
>   How do you launch it? By dble-clicking on it? If yes, try to check the
>   console (there's an app named Console somewhere, can't recall where
>   but you'll probably find it).
>=20
> -- S=E9bastien.

Re: [Modeling-users] Re: attaching information to a relation

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

On Samedi, ao=FB 9, 2003, at 14:32, Sebastien Bigaret wrote:
> Mario Ruggier <ma...@ru...> wrote:
>>>    In fact my previous post was about something like this:
>>>
>>>      Association('TypedAssoc','User',
>>>        relations=3D['user','typed_assocs'],
>>>        delete=3D['nullify','cascade'],
>>>        keys=3D['FK_User_id','id']
>>>      ),
>>>      Association('TypedAssoc','Address',
>>>        relations=3D['address','typed_assocs'],
>>>        delete=3D['nullify','cascade'],
>>>        keys=3D['FK_Address_id','id']
>>>
>>>    i.e.  User <----->> TypedAssoc <<-----> Address
>>
>> Hmmn, it seems I have switched the logic around.
>> In this way the "user" and "address" relations show up as constraints
>> on the TypedAssoc table.
>>
>> But, the problem with this is that if we re-use TypedAssoc
>> also for a similar association between User and Organization
>> (using this naming strategy) then there will be the ValueError
>> mentioned above. Hence, using a  <source4target> naming
>> scheme for these relations, and adding the ones for organization,
>> we end up with a TypedAssoc definition of:
>>
>> CREATE TABLE TypedAssoc (
>>    FK_USER_ID INTEGER ,
>>    FK_ORGANIZATION_ID INTEGER ,
>>    TYPE VARCHAR(30) ,
>>    ID INTEGER NOT NULL PRIMARY KEY,
>>    FK_ADDRESS_ID INTEGER ,
>>    CONSTRAINT address4user FOREIGN KEY (FK_USER_ID) REFERENCES=20
>> Address(ID),
>>    CONSTRAINT organization4user FOREIGN KEY (FK_ORGANIZATION_ID)=20
>> REFERENCES
>> Organization(ID),
>>    CONSTRAINT user4address FOREIGN KEY (FK_ADDRESS_ID) REFERENCES=20
>> User(ID),
>>    CONSTRAINT user4organization FOREIGN KEY (FK_USER_ID) REFERENCES=20=

>> User(ID))
>>
>> Is this correct? This will rule out re-use of such a table...
>
> I *think* this should work (even if untested, I've never gathered all
> correlation tables into a single one. However I feel that some things
> still needs to be fixed:
>
>   1. there's a missing name for TYPE VARCHAR(30),

The name is "Type"... What type of name would you like ;-?

>   2. constraints are not ok, I'd write:
>
>     CONSTRAINT address4user FOREIGN KEY (FK_ADDRESS_ID) REFERENCES=20
> Address(ID),
>     CONSTRAINT organization4user FOREIGN KEY (FK_ORGANIZATION_ID)=20
> REFERENCES
>          Organization(ID),
>     CONSTRAINT user4address FOREIGN KEY (FK_USER_ID) REFERENCES=20
> User(ID),
>     CONSTRAINT user4organization FOREIGN KEY (FK_USER_ID) REFERENCES=20=

> User(ID))

This was my mistake, in the pymodel...

> Last, the correlation tables has now 3 FKs: FK_USER_ID, FK_ADDRESS_ID
> and FK_ORGANIZATION_ID. It should work, given that each row in
> TypedAssoc only has two non null FKs.

Such constraints (must have 2 and only 2 non-null FKs) can only be
checked in python code (not in the model) ?

(Repeated question) Even if it is possible to do such a thing, is it a=20=

good
idea to re-use such a TypedAssoc table, or should a dedicated one be
made for each association? In addition to the constraint mentioned=20
above,
there is the issue of scalability -- that a table with less cols and=20
more rows
scales better than a table with more cols and less rows...

>> Question: why is the order in an association important?
[snip]

Thanks for the reminder/clarification of the multiplicity defaults on=20
Assocations...

mario

Re: [Modeling-users] Re: attaching information to a relation

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

On Samedi, ao=FB 9, 2003, at 14:36, Sebastien Bigaret wrote:
> I wrote:
>> The problem is that you were probably misled here by the names: since
>> you read 'typed_assocs' and 'user', you tend to think that=20
>> associations
>> are resp. to-many and to-one, and since the cardinalities are =
implicit
>> here, that makes it harder to see the problem. In fact,
>>
>>        Association('User','TypedAssoc',
>>          relations=3D['typed_assocs','user'],
>>          delete=3D['cascade','nullify'],
>>          keys=3D['id','FK_User_id']
>>
>> is equivalent to (see Association's defaults):
>>
>>        Association('User','TypedAssoc',
>>          relations=3D['typed_assocs','user'],
>>          multiplicity=3D[ [0,1], [0,None] ],
>>          delete=3D['cascade','nullify'],
>>          keys=3D['id','FK_User_id']
>>
>>   and this version makes the pb appears clearly, doesn't it? ;)
>
> Now I really wonder if this was a so good idea to allow the=20
> multiplicity
> to be implicit. If you remember the discussion on this topic, we made=20=

> it
> implicit becauser it allows a more concise declarations of=20
> associations.
> However, this obviously lead, leads (and will lead) to problems, just
> because we human-beings interpret things a lot more than machines do =
:)
>
>   It may be really better to make the multiplicity explicit in
>   associations (so that it is required in each declaration of
>   association), and allow it to be either E1 <<---> E2 (the only
>   possible case for now) or E1 <--->> E1.
>
> What do you think, all?

Thanks for all the replies and fixes...

To answer to this issue - well, I certainly fell into this trap (but I
am particularly forgetful ;).  Anyhow, even if I generally prefer=20
clarify
and explicitness in code, i feel that in this case it is still better=20
not
to require that "multiplicity" be stated on each assoc, as it risks to=20=

quickly
become "noise" -- my feeling is that copy-pasting the same line all over
the place will anyhow render that line invisible quite quickly, so if we
change it once every 20 occurances or so, we would never notice the
one that is different, thus it will actually be better for the=20
non-deviant lines
not to be there, as things would be thus made clearer.

I would prefer a systematic practice of stating all the defaults at the=20=

top
of each model file, even those that are not different form the defaults
set in PyModel.py. Each Assoc and other constructs will then only
use statements that differ from these defaults. Thus in this case, we
will add to defaults section, at top of each model:

Association.defaults['multiplicity']=3D[ [0,1], [0,None] ]

Any opinion from the others?

On a related note, would we want a "collection" of models to share the
same defaults? Can we make the (custom) declarations of these defaults
common to several models?

Cheers, mario

Re: [Modeling-users] fetch qualifier problem

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

Sebastien Bigaret <sbi...@us...> wrote:
> This is a problem w/ sqlite. The problem happens for '_' and '%', and I
> can't even find out to do this on the sqlite commandline. I've just sent
> the question to the sqlite ml, we'll see then.

  Two notes:

    - I added bug #785913 for this,

    - the Postgresql layer had the same pb. w/ '_' (was okay for '%'); I
      noticed this when writing the related test. This is fixed on CVS, and
      you'll find attached a patch correcting the bug.

        Regards,

-- S=E9bastien.

------------------------------------------------------------------------
--- Modeling/DatabaseAdaptors/PostgresqlAdaptorLayer/PostgresqlSQLExpressio=
n.py3 Aug 2003 10:34:14 -0000        1.6
+++ Modeling/DatabaseAdaptors/PostgresqlAdaptorLayer/PostgresqlSQLExpressio=
n.py9 Aug 2003 15:10:11 -0000        1.7
@@ -27,11 +27,11 @@
=20
   CVS information
=20
-    $Id: PostgresqlSQLExpression.py,v 1.6 2003/08/03 10:34:14 sbigaret Exp=
 $
+    $Id: PostgresqlSQLExpression.py,v 1.7 2003/08/09 15:10:11 sbigaret Exp=
 $
=20=20=20
 """
=20
-__version__=3D'$Revision: 1.6 $'[11:-2]
+__version__=3D'$Revision: 1.7 $'[11:-2]
=20
 from Modeling.SQLExpression import SQLExpression, DateType, CharacterType
 import string
@@ -115,8 +115,8 @@
     Overrides default behaviour so that '%' is changed to '\\%' instead of
     '\%': postgresql interprets backslashes in strings
     """
-    pattern=3Dpercent.sub('\\\\\\\\%', pattern)
-    pattern=3Dunderscore.sub('\_', pattern)
+    pattern=3Dpercent.sub(r'\\\\%', pattern)
+    pattern=3Dunderscore.sub(r'\\\\_', pattern)
     pattern=3Descaped_question_mark.sub(esc_question_tmp_replct, pattern)
     pattern=3Dquestion_mark.sub('_', pattern)
     pattern=3Descaped_star.sub(esc_star_tmp_replct, pattern)

Re: [Modeling-users] fetch qualifier problem

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

Mario Ruggier <ma...@ru...> writes:

> Sorry, I did not mention that this was running on sqlite.
> The problem here occurs for string values that contain '_'
> (for '@'. it actually works fine, sorry had it wrong the first time).

This is a problem w/ sqlite. The problem happens for '_' and '%', and I
can't even find out to do this on the sqlite commandline. I've just sent
the question to the sqlite ml, we'll see then.

> Small question: when i try the aove from inside a py program
> (a unittest testcase test), setting this envvar to 'YES', nothing happens=
...
> or so it seems. Where should i go to get stderr (osx) ?

  How do you launch it? By dble-clicking on it? If yes, try to check the
  console (there's an app named Console somewhere, can't recall where
  but you'll probably find it).

-- S=E9bastien.

Re: [Modeling-users] fetch qualifier problem

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

Sorry, I did not mention that this was running on sqlite.
The problem here occurs for string values that contain '_'
(for '@'. it actually works fine, sorry had it wrong the first time).

Here is a (touched-up, to remove stuff) SQL output:

 >>> ufirst =3D '_mario'
 >>> u =3D ec.fetch('User',qualifier=3D'firstname ilike "*%s*"' =
%(ufirst) )
Opening channel=20
<SQLiteAdaptorLayer.SQLiteAdaptorChannel.SQLiteAdaptorChannel instance=20=

at 0x7db8e0> (0x7db8e0)
Called
Opening connection to the DB with conn.Dict: {'password': 'xxxx',=20
'database': 'db_users'}
Evaluating: SELECT t0.ID, t0.FIRSTNAME, t0.etcetera, FROM User t0 WHERE=20=

UPPER(t0.FIRSTNAME) LIKE UPPER('%\_mario%')
rowcount: 0 Returning: None
Closing adaptorChannel=20
<SQLiteAdaptorLayer.SQLiteAdaptorChannel.SQLiteAdaptorChannel instance=20=

at 0x7db8e0> (0x7db8e0)
Adaptor channel=20
<SQLiteAdaptorLayer.SQLiteAdaptorChannel.SQLiteAdaptorChannel instance=20=

at 0x7db8e0> did close
Channels are now all closed
Closing the connection to the database
 >>>

Small question: when i try the aove from inside a py program
(a unittest testcase test), setting this envvar to 'YES', nothing=20
happens...
or so it seems. Where should i go to get stderr (osx) ?

mario



On Samedi, ao=FB 9, 2003, at 14:43, Sebastien Bigaret wrote:
>         Hi,
>
>   Could you please give an example string and the db server you use?
>
>   It must be a bug. '_' is the sql equivalent for '?' in qualifier
> strings (matches one character), but it should have been escaped. We=20=

> had
> such pbs with postgresql which were fixed, but it seems that the
> pb. remains w/ other db adaptors.  AFAIK '@' shouldn't be a problem on
> its own.
>
>   It could also help if you could send the generated sql statements by
>   setting MDL_ENABLE_DATABASE_LOGGING to true --possibly privately if
>   you do not want to disclose the details.
>
>
> -- S=E9bastien.
>
>
> Mario Ruggier <ma...@ru...> wrote:
>> I have encountered this problem: if i set a string property on an=20
>> entity,
>> and this contains a "special" character such as _ or @, then fetch
>> does the following:
>>
>> ec.EditingContext()
>> aprop =3D 'a_string' # contains a special characters, e.g. _ @
>> e =3D AnEntity()
>> e.setAprop(aprop)
>> ec.insert(e)
>> ec.saveChanges()
>>
>> ec.fetch('AnEntity',qualifier=3D'aprop =3D=3D "%s"' %(aprop) ) # =
works fine
>> ec.fetch('AnEntity',qualifier=3D'aprop ilike "*%s*"' %(aprop) ) # =
nada
>>
>> i.e. if i use the str value for testing equality, the fetch results=20=

>> are ok,
>> but if i use it in ilike, then the fetch result list is zero length.
>> Is there something i miss here, or is this a bug?
>>
>> Cheers, mario
>

Re: [Modeling-users] fetch qualifier problem

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

        Hi,

  Could you please give an example string and the db server you use?

  It must be a bug. '_' is the sql equivalent for '?' in qualifier
strings (matches one character), but it should have been escaped. We had
such pbs with postgresql which were fixed, but it seems that the
pb. remains w/ other db adaptors.  AFAIK '@' shouldn't be a problem on
its own.

  It could also help if you could send the generated sql statements by
  setting MDL_ENABLE_DATABASE_LOGGING to true --possibly privately if
  you do not want to disclose the details.


-- S=E9bastien.


Mario Ruggier <ma...@ru...> wrote:
> I have encountered this problem: if i set a string property on an entity,
> and this contains a "special" character such as _ or @, then fetch
> does the following:
>=20
> ec.EditingContext()
> aprop =3D 'a_string' # contains a special characters, e.g. _ @
> e =3D AnEntity()
> e.setAprop(aprop)
> ec.insert(e)
> ec.saveChanges()
>=20
> ec.fetch('AnEntity',qualifier=3D'aprop =3D=3D "%s"' %(aprop) ) # works fi=
ne
> ec.fetch('AnEntity',qualifier=3D'aprop ilike "*%s*"' %(aprop) ) # nada
>=20
> i.e. if i use the str value for testing equality, the fetch results are o=
k,
> but if i use it in ilike, then the fetch result list is zero length.
> Is there something i miss here, or is this a bug?
>=20
> Cheers, mario

Re: [Modeling-users] Re: attaching information to a relation

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

I wrote:
> The problem is that you were probably misled here by the names: since
> you read 'typed_assocs' and 'user', you tend to think that associations
> are resp. to-many and to-one, and since the cardinalities are implicit
> here, that makes it harder to see the problem. In fact,=20
>=20
>        Association('User','TypedAssoc',
>          relations=3D['typed_assocs','user'],
>          delete=3D['cascade','nullify'],
>          keys=3D['id','FK_User_id']
>=20
> is equivalent to (see Association's defaults):
>=20
>        Association('User','TypedAssoc',
>          relations=3D['typed_assocs','user'],
>          multiplicity=3D[ [0,1], [0,None] ],
>          delete=3D['cascade','nullify'],
>          keys=3D['id','FK_User_id']
>=20
>   and this version makes the pb appears clearly, doesn't it? ;)

Now I really wonder if this was a so good idea to allow the multiplicity
to be implicit. If you remember the discussion on this topic, we made it
implicit becauser it allows a more concise declarations of associations.
However, this obviously lead, leads (and will lead) to problems, just
because we human-beings interpret things a lot more than machines do :)

  It may be really better to make the multiplicity explicit in
  associations (so that it is required in each declaration of
  association), and allow it to be either E1 <<---> E2 (the only
  possible case for now) or E1 <--->> E1.=20

What do you think, all?

        Regards,

-- S=E9bastien.

[Modeling-users] fetch qualifier problem

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

Hello,

I have encountered this problem: if i set a string property on an 
entity,
and this contains a "special" character such as _ or @, then fetch
does the following:

ec.EditingContext()
aprop = 'a_string' # contains a special characters, e.g. _ @
e = AnEntity()
e.setAprop(aprop)
ec.insert(e)
ec.saveChanges()

ec.fetch('AnEntity',qualifier='aprop == "%s"' %(aprop) ) # works fine
ec.fetch('AnEntity',qualifier='aprop ilike "*%s*"' %(aprop) ) # nada

i.e. if i use the str value for testing equality, the fetch results are 
ok,
but if i use it in ilike, then the fetch result list is zero length.
Is there something i miss here, or is this a bug?

Cheers, mario