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

[Modeling-users] primary key + class property

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I saw in the FAQ that I could see my primary keys by setting them as
class properties.  If I try this, I need to set them by hand.  

How can I have *automatic* primary keys that I can see ?

I really need to see my primary keys in order to cross an XML-RPC bridge.

Regards, 

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+VTFArhy5Fqn/MRARAlDxAJwJC4IS7rj7ybmiE/d4TBDG1HhongCfSLWU
NJAJyx92thpzigNpFZ0TQqk=
=if65
-----END PGP SIGNATURE-----

Re: [Modeling-users] entity import takes a lot of cpu

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 20 February 2003 12:37 pm, Sebastien Bigaret wrote:
> I plan to release another script for ``compiling'' a model, with the
> generated __init__.py for that purpose.

It was exactly what I thought would be best !

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+VSehrhy5Fqn/MRARAjD3AKCTS8zjcHGfzyLHL/m/k9V4mV5jyACfXOrS
8pDYO6+4+hkVuzS04DVeETk=
=cb9E
-----END PGP SIGNATURE-----

Re: [Modeling-users] fetching problem

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 20 February 2003 01:03 pm, Sebastien Bigaret wrote:
> BTW this question is addressed in section 2.6 / FAQ of the User's
> Guide ;) but if you read it and did not understand that way, please
> tell me

The FAQ is explicit, you could provide it as a top level instead of nesting it
inside a sub-section to help dumb people (like me) notice it.

> However, you did find a bug here: it shouldn't raise UnboundLocalError
> but at least something more informative! Could you please take some time
> and fill in a bug report in sourceforge's tracker?

Done, it's bug no. 690224

Regards,

- --
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+VScyrhy5Fqn/MRARArq+AJ0RgCEyv99/GbYMWUuZV8/mr46C4ACfajD8
brAeGeiD37ZJi0tHwNWr4Y4=
=g3UO
-----END PGP SIGNATURE-----

Re: [Modeling-users] fetching problem

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

Another quick answer:

> > But I can't fetch any value, the following code :
> >
> >  from Modeling.EditingContext import EditingContext
> >  from Modeling.FetchSpecification import FetchSpecification
> >  from Autogen.PROJECT import PROJECT
>=20
> I found the problem, the import statement was edited for the email, it
> really was from core.utils.Autogen import PROJECT.  The if I flatten
> my hierarchy a bit to REALLY have from Autogen.PROJECT import PROJECT,
> it works perfectly.
>=20
> Do you plan to support sub-package import in future releases ?

Okay, I think I see your problem: you generated the python code
templates with the model you supplied in your previous mail, than you
put the generated package in package core.utils.

If true, the only thing you need to change is attribute 'packageName' of
xml-entity <model>: change it from 'Autogen' to 'core.utils.Autogen',
and you'll see that your entities can now find their own classes (you'll
probably want to modify both model_Autogen.xml and model_Autogen.py)

  BTW this question is addressed in section 2.6 / FAQ of the User's
  Guide ;) but if you read it and did not understand that way, please
  tell me

However, you did find a bug here: it shouldn't raise UnboundLocalError
but at least something more informative! Could you please take some time
and fill in a bug report in sourceforge's tracker?

        Cheers,

-- S=E9bastien.

Re: [Modeling-users] entity import takes a lot of cpu

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

        Hi,

  I'm answering very quickly so please excuse if my typos and bad engli=
sh.

Yannick Gingras <yan...@sa...> writes:
> On Wednesday 19 February 2003 01:35 pm, Yannick Gingras wrote:
> > This delay is not showed in the python profiler so I assume that th=
e time
> > is spent in a C module.  Is the XML parser that CPU hungry ?
>=20
> Oups !
>=20
> The delay clearly shows in the profiler, the import statement was exe=
cuted=20
> before I start profiling.=20=20
>=20
> [snip]
> It seems clear to me that either we our DOM implementation is really
> unefficient or my model is too complex.  Having 40 entities in my
> model, I think it should be easy to parse.
>=20
> Anyone had the same problem ?

You're not alone! Loading the xml-model *does* consume a lot of cpu. At
the very beginning I had a simple sax parser, but I quickly switched to
DOM & XPath because it made the implementation a lot clearer. However, I
kind of regret this by now because it takes a lot of time to load an xml
model.

  I plan to release another script for ``compiling'' a model, with the
  generated __init__.py for that purpose. In the meantime I can give you
  a sample script you may want to adapt to your model (you'll find it at
  the end of the message). It does something really simple: it loads a
  model, pickles it, and drops the result into a dedicated module's
  string-field (dropping it in a model makes it possible to install it
  w/ distutils, as usual). This makes the process of loading a model a
  lot quicker; however pickle is very sensitive wrt to its environment,
  hence great care must be taken so that the python executable compiling
  the model is the very same than the one loading it, being executed on
  the same platform, etc.

  It also requires a little adaptation of the generated __init__.py,
  you'll also find sample code for that at the end of the message (don't
  forget to query/replace all occurences of MODEL_NAME with yours).

Sorry, I do not have the time to check that everything will work as
expected but it's mostly copy-pasted from a working project, hopefully
the changes you may have to make won't be too expensive.

  You can consider that these two samples of code are in public domain.

  Please tell me if you have any problem with this.

-- S=E9bastien.


------------------------------------------------------------------------
#! /usr/bin/env python
"""
compile_model.py

  ``Compile'' an xml_model into two python modules, model_<modelName>.p=
y and
  model_<modelName>_pickled.py:

    - model_<model_name>.py: contains the whole xml-file in a single mo=
dule
        attribute: model_src
=20=20
    - model_<modelName>_pickled.py: the second one contains a single at=
tribute
        as well: model_pickle, which is a raw string to be loaded by
        cPickle.loads()
=20=20=20=20=20=20
  Written by: Sebastien Bigaret
"""
import sys, getopt

def loadModel(xmlFilePath):
  """
  Creates a python module (file: model_<modelName>.py) and dumps the
  content of the file 'xmlFilePath' in a string attribute named 'model_=
src'
  """
  from Modeling import ModelSet
  ms=3DModelSet.ModelSet()
  ms.addModelFromXML({'file': xmlFilePath})
  model=3Dms.models()[0]
  model._modelSet=3DNone
  return model

def write_xml_model_in_python_module(xmlFilePath, modelName):
  """
  Creates a python module (file: model_<modelName>.py) and dumps the
  content of the file 'xmlFilePath' in a string attribute named 'model_=
src'
  """
  xml=3Dopen(xmlFilePath, 'r')
  file=3Dopen('model_%s.py'%modelName, 'w')
  file.write('model_src=3D"""')
  s=3Dxml.readline()
  while s!=3D'':
    file.write(s)
    s=3Dxml.readline()
  file.write('"""\n')
  xml.close()
  file.close()
=20=20
def write_pickled_model(model):
  """
  Creates a python module (file: model_<modelName>_pickle.py) and dumps=
 a
  pickled version of the supplied model in module's attribute 'model_pi=
ckle'.
  """
  import cPickle
  file=3Dopen('model_%s_pickle.py'%model.name(), 'w')
  file.write('model_pickle=3Dr"""')
  pickled=3DcPickle.dump(model, file)
  file.write('"""\n')
  file.close()

def usage(prgName, exitStatus=3DNone):
  print """%s <model.xml>
``Compile'' an xml_model into two python modules, model_<modelName>.py =
and
model_<modelName>_pickled.py.

  - model_<model_name>.py: contains the whole xml-file in a single modu=
le
      attribute: model_src

  - model_<modelName>_pickled.py: the second one contains a single attr=
ibute
      as well: model_pickle, which is a raw string to be loaded by
      cPickle.loads()

Options
-------
  -h           Prints this message
""" % prgName
  if exitStatus is not None:
    sys.exit(exitStatus)

def main(argv):
  me=3Dargv[0]

  try:
    options, args =3D getopt.getopt(sys.argv[1:], 'h')
  except getopt.GetoptError,msg:
    print me, msg
    usage(me, 1)
=20=20=20=20
  verbose=3D0
=20=20
  for k, v in options:
    if k=3D=3D'-h': usage(me, 0)

  if len(args)!=3D1:
    usage(me,1)
=20=20=20=20
  model=3DloadModel(args[0])
  write_xml_model_in_python_module(args[0], model.name())
  write_pickled_model(model)

=20
if __name__ =3D=3D "__main__":
  main(sys.argv)

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

------------------------------------------------------------------------
# modified __init__.py for your package
##
## !!! REPLACE ALL OCCURRENCES OF MODEL_NAME WITH _YOUR_ modelName !!!
##

from Modeling import ModelSet
import os, warnings, cStringIO, traceback

def loadModel():
  """
  Loads the model. It searches for:

    1. a pickled raw string stored in attribute 'model_pickle' in module
       'model_<modelName>_pickle', if it exists

    2. then, a xml-string stored in attribute 'model_str' in module
       'model_<modelName>', if it exists

    3. last, a xml file 'model_<model_Name>.xml'


  cf. script compile_model.py and its usage
  """
  try:
      from model_MODEL_NAME_pickle import model_pickle
      import cPickle
      m=3DcPickle.loads(model_pickle)
      ModelSet.defaultModelSet().addModel(m)
      model=3DModelSet.defaultModelSet().modelNamed('MODEL_NAME')
  except:
    exc=3DcStringIO.StringIO()
    traceback.print_exc(file=3Dexc)
    warnings.warn("Couldn't load model from pickle'\n"\
                  "Reason:\n%s"%exc.getvalue())
    del exc
  else:
    return
=20=20
  try:
    from model_MODEL_NAME import model_src
    ModelSet.defaultModelSet().addModelFromXML({'string': model_src})
    model=3DModelSet.defaultModelSet().modelNamed('MODEL_NAME')
  except:
    exc=3DcStringIO.StringIO()
    traceback.print_exc(file=3Dexc)
    warnings.warn("Couldn't load model from 'model_MODEL_NAME.py'\nReas=
on:\n%s"%exc.getvalue())
    del exc
  else:
    return

  # Or, alternatively: use the xml file (ok for dev. mode, not for inst=
all w/
  # distutils)
  #
  from os import getcwd, path
  mydir =3D os.path.abspath(os.path.dirname(__file__))
  xmlmodelPath=3Dpath.join(mydir,'model_MODEL_NAME.xml')
  ModelSet.defaultModelSet().addModelFromXML({'file': xmlmodelPath})
  model=3DModelSet.defaultModelSet().modelNamed('MODEL_NAME')

if ModelSet.defaultModelSet().modelNamed('MODEL_NAME') is None:
  loadModel()
------------------------------------------------------------------------

Re: [Modeling-users] fetching problem

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 20 February 2003 11:11 am, Yannick Gingras wrote:
> But I can't fetch any value, the following code :
>
>  from Modeling.EditingContext import EditingContext
>  from Modeling.FetchSpecification import FetchSpecification
>  from Autogen.PROJECT import PROJECT

I found the problem, the import statement was edited for the email, it really 
was from core.utils.Autogen import PROJECT.  The if I flatten my hierarchy a 
bit to REALLY have from Autogen.PROJECT import PROJECT, it works perfectly.

Do you plan to support sub-package import in future releases ?

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+VQjfrhy5Fqn/MRARArkOAJ93CF0Z3mGvGBt2ZwUI3HHmiI8x7ACeOgWQ
9a9VLblnIn9pdN0ggxJnr/M=
=cFZP
-----END PGP SIGNATURE-----

[Modeling-users] fetching problem

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,
  I have a really simple model with one entity.  I can insert from it but I
can't fetch.  Here it is, normalized with xmlpp :

<?xml version='1.0' encoding='iso-8859-1'?>

<model
  adaptorName='MySQL'
  connectionDictionary="{}"
  name='Autogen'
  packageName='Autogen'
>
  <entity
    className='PROJECT'
    externalName='PROJECT'
    isAbstract='0'
    isReadOnly='0'
    moduleName='PROJECT'
    name='PROJECT'
    parentEntity=''
    typeName=''
  >
    <primaryKey
      attributeName='projectId'
     />
    <attribute
      columnName='activ_status_id'
      defaultValue='0'
      displayLabel=''
      externalType='INTEGER'
      isClassProperty='1'
      isRequired='1'
      name='activStatusId'
      precision='0'
      scale='0'
      type='int'
      width='5'
     />
    <attribute
      columnName='project_code'
      defaultValue=''
      displayLabel=''
      externalType='varchar'
      isClassProperty='1'
      isRequired='1'
      name='projectCode'
      precision='0'
      scale='0'
      type='string'
      width='30'
     />
    <attribute
      columnName='project_id'
      defaultValue='0'
      displayLabel=''
      externalType='INTEGER'
      isClassProperty='0'
      isRequired='1'
      name='projectId'
      precision='0'
      scale='0'
      type='int'
      width='5'
     />
    <attribute
      columnName='project_note'
      defaultValue=''
      displayLabel=''
      externalType='varchar'
      isClassProperty='1'
      isRequired='1'
      name='projectNote'
      precision='0'
      scale='0'
      type='string'
      width='100'
     />
  </entity>
</model>

I can easily insert with this code snipet :

 from Autogen.PROJECT import PROJECT
 from Modeling.EditingContext import EditingContext

 CODE = "55-00m"
 DESC = "Wash the dishes..."

 if __name__ == '__main__':
     ec = EditingContext()
     proj = PROJECT()
     proj.setProjectCode(CODE)
     proj.setProjectNote(DESC)
     proj.setActivStatusId(18)

     ec.insertObject(proj)
     ec.saveChanges()

     print "done !"

But I can't fetch any value, the following code :

 from Modeling.EditingContext import EditingContext
 from Modeling.FetchSpecification import FetchSpecification
 from Autogen.PROJECT import PROJECT

 ec = EditingContext()
 fetchSpec=FetchSpecification(entityName='PROJECT')
 projects = ec.objectsWithFetchSpecification(fetchSpec)

Raises a weird UnboundLocalError :

Traceback (most recent call last):
  File "<stdin>", line 14, in ?
  File "/usr/lib/python2.2/site-packages/Modeling/EditingContext.py", line
1063, in objectsWithFetchSpecification
    return
self.parentObjectStore().objectsWithFetchSpecification(aFetchSpecification,
anEditingContext)
  File "/usr/lib/python2.2/site-packages/Modeling/ObjectStoreCoordinator.py",
line 421, in objectsWithFetchSpecification
    return store.objectsWithFetchSpecification(aFetchSpecification,
anEditingContext)
  File "/usr/lib/python2.2/site-packages/Modeling/DatabaseContext.py", line
1441, in objectsWithFetchSpecification
    object=channel.fetchObject()
  File "/usr/lib/python2.2/site-packages/Modeling/DatabaseChannel.py", line
217, in fetchObject
    object=cd.createInstanceWithEditingContext(ec)
  File "/usr/lib/python2.2/site-packages/Modeling/EntityClassDescription.py",
line 177, in createInstanceWithEditingContext
    theClass=self.classForInstances()
  File "/usr/lib/python2.2/site-packages/Modeling/EntityClassDescription.py",
line 161, in classForInstances
    theClass=classForEntity(self._entity)
  File "/usr/lib/python2.2/site-packages/Modeling/EntityClassDescription.py",
line 488, in classForEntity
    retClass=getattr(module, className, None)
UnboundLocalError: local variable 'module' referenced before assignment


The model passes all the validations, what could I have possibly done wrong ?


- --
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+VP5Erhy5Fqn/MRARAiwUAJ4iNHXMPWedtSdt+WBV69tyY++ObwCghzEX
ChFXvP9TY3qVHMQWgQIfROE=
=k7Cz
-----END PGP SIGNATURE-----

Re: [Modeling-users] entity import takes a lot of cpu

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 19 February 2003 01:35 pm, Yannick Gingras wrote:
> This delay is not showed in the python profiler so I assume that the time
> is spent in a C module.  Is the XML parser that CPU hungry ?

Oups !

The delay clearly shows in the profiler, the import statement was executed 
before I start profiling.  

I have the following log : 
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
280812/263643    5.080    0.000    7.880    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/dom/FtNode.py:79(__getattr__)
   109449    1.870    0.000    2.570    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/xpath/yappsrt.py:111(_peek)
     3086    1.240    0.000    6.440    0.002 
/usr/lib/python2.2/site-packages/_xmlplus/dom/Element.py:182(setAttributeNodeNS)
     3494    1.080    0.000    1.270    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/xpath/XPathGrammar.py:716(__init__)
    13048    0.830    0.000    3.860    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/dom/FtNode.py:371(_4dom_fireMutationEvent)
     3086    0.820    0.000    1.710    0.001 
/usr/lib/python2.2/site-packages/_xmlplus/dom/NamedNodeMap.py:107(setNamedItemNS)
   129785    0.810    0.000    0.810    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/xpath/XPathGrammar.py:782(token)
     3439    0.800    0.000    1.660    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/dom/FtNode.py:382(_4dom_validateNode)
    38117    0.800    0.000    1.570    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/xpath/ParsedNodeTest.py:130(match)
     6525    0.760    0.000    0.950    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/dom/Event.py:37(__init__)
    13048    0.740    0.000    1.280    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/dom/FtNode.py:307(dispatchEvent)
     9856    0.690    0.000    1.530    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/dom/Attr.py:40(_get_value)
     3336    0.680    0.000    3.060    0.001 
/usr/lib/python2.2/site-packages/_xmlplus/xpath/ParsedAxisSpecifier.py:101(select)
     3494    0.560    0.000   17.770    0.005 
/usr/lib/python2.2/site-packages/_xmlplus/xpath/__init__.py:60(Evaluate)
    35042    0.540    0.000    2.050    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/xpath/ParsedAxisSpecifier.py:104(<lambda>)
      254    0.540    0.002   15.670    0.062 
/usr/lib/python2.2/site-packages/Modeling/Attribute.py:520(initWithXMLDOMNode)
    25233    0.470    0.000    0.480    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/dom/NodeList.py:25(__getattr__)
     3494    0.440    0.000   12.210    0.003 
/usr/lib/python2.2/site-packages/_xmlplus/xpath/pyxpath.py:317(parse)
    20336    0.420    0.000    0.530    0.000 
/usr/lib/python2.2/site-packages/_xmlplus/xpath/yappsrt.py:117(_scan)

It seems clear to me that either we our DOM implementation is really
unefficient or my model is too complex.  Having 40 entities in my
model, I think it should be easy to parse.

Anyone had the same problem ?

Any quick solutions ?

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+U9Yqrhy5Fqn/MRARAupwAJ4k8ztpwHyoKJK4+eSSRtNYzBYppQCfWbl6
SpiGZAVkm699Qk0utI+ocJ4=
=EUKZ
-----END PGP SIGNATURE-----

[Modeling-users] entity import takes a lot of cpu

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi, 
  I'm wondering if it's just me but as soon as I add an import statement for 
an entity inside my model my startup is at least 15 seconds slower.

Anyone else has the same problem ?

How can I speed-up things a bit ?

This delay is not showed in the python profiler so I assume that the time is 
spent in a C module.  Is the XML parser that CPU hungry ?

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+U86Lrhy5Fqn/MRARAuTtAJ9PzI+Q2/Xjf2FVHdd5YB0DHHwZagCfey+z
rbc2Lo2lFWp61uCXcdyaq9g=
=IIvk
-----END PGP SIGNATURE-----

[Modeling-users] Name for methods valueForKey and takeValueForKey?

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

Hi,

i find these names unclear, and even disturbing \-;
Should it ever be possible to change them, and if these names
should avoid using 'get' and 'set' not to clash with dedicated getters 
and setters,
then, instead of:

valueForKey 		valueForKeyPath
takeValueForKey   	takeValueForKeyPath

I can suggest names such as:

retrieveKeyValue 	retrieveKeyPathValue
assignKeyValue   	assignKeyPathValue

or

valueFromKey		valueFromKeyPath
valueForKey		valueForKeyPath

or, more consistently, if we reserve the attribute names
valueByKey and valueByKeyPath:

getValueByKey	getValueByKeyPath
setValueByKey		setValueByKeyPath

or, even simpler and more elegant (but need extra check per call)
is to just have the following two methods (reserving attribute name
keyValue), and determine dynamically whether key specified is
a simple key or a path (check for '.' should be enough?)

getKeyValue		
setKeyValue


Cheers, mario

[Modeling-users] XML model suggestion

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

Hello,

familiarizing myself with the framework, I suggest the following
modification to the XML to describe a model:

  Instead of the XML elements:

       <primaryKey ...
       <attributesUsedForLocking ...

use XML attributes on the <attribute> XML element, i.e.

       <attribute ... primaryKey="1" ...
       <attribute ... usedForLocking="1" ...

This seems clearer, is less verbose, and in any case keeps open
your options to support changing your mind about enforcing only one such
attribute for each case -- should the framework evolve that way.

mario

[Modeling-users] About release 0.9

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

        Hi all,

I wrote:
>   We are on our way to public v0.9, which has already been put in
>   production for more than 3 months now and is considered stable. V0.9
>   is still planned for the end of the week (it might be late a week,
>   though). One or two minor releases will probably be necessary befor=
e 0.9.

  Just a quick note to inform you that some personal events will keep m=
e away
  from my computer until wednesday, meaning that release 0.9 is
  postponed. I'll try hard to make it available next friday or saturday=
 ; but
  I fear that I will not have the time to update the documentation at t=
hat
  time, hence that release will certainly be 0.9-pre1, just including b=
ug
  fixes and feature #617997, and 0.9 will be released afterwards with
  doc. updated.

    Sorry for the delay, regards,

-- S=E9bastien.

Re: [Modeling-users] Domain Model DTD

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

> On Wednesday 12 February 2003 09:35 am, Yannick Gingras wrote:
> > As I read the archive I understand that there is no DTD for the dom=
ain
> > model.  Is still true for 0.8 ?
>=20
> I mean : "Is this still true for 0.8.5 ?"

  Well, I've almost never played with DTD, this must be the reason why
  there's no official DTD...

Section 2.2 in the User's Guide fully describes the format. Given this,
I've just quickly derived what could be the official DTD if only I knew
what I was doing ;) You'll find it attached to this email. The only
thing I can tell is that emacs sgml-mode does not yell at me when I ask
him to validate any xml models included in the test packages (given that
I added <!DOCTYPE model SYSTEM "mdl_model.dtd"> to the prologue)
Note: sgml-mode triggers nsgmls for validation.


  If anyone here has some knowledge about DTDs, please comment!
  Moreover, if you have an idea on how a DTD can be used to validate a
  xml-file when loading it into a DOM object (in python), I'll be really
  happy to hear from it (a quick google search did not teach me a lot,
  and I've no time to search any longer for now).


-- S=E9bastien.

Re: [Modeling-users] Domain Model DTD

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 12 February 2003 09:35 am, Yannick Gingras wrote:
> As I read the archive I understand that there is no DTD for the domain
> model.  Is still true for 0.8 ?

I mean : "Is this still true for 0.8.5 ?"

 : )

- --
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+Sl4Orhy5Fqn/MRARAjvMAJ40wmBOjZ1OiQpTDocJS30rYT51XwCeJl7k
pvJTY+9RUZTUqEi40K+FYSY=
=1QS/
-----END PGP SIGNATURE-----

[Modeling-users] Domain Model DTD

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


As I read the archive I understand that there is no DTD for the domain
model.  Is still true for 0.8 ?

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+Slucrhy5Fqn/MRARAiteAJ9xYi+bHa1FSbZ9nFF5hG9CcGArmwCfbe0w
3a6ae0KllB3cXd6e6wefhs4=
=6TRv
-----END PGP SIGNATURE-----

Re: [Modeling-users] Oracle DB Adapter

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

        Hi,

> I took a quick look at the MySQL and Postgresql adapters and I'm
> wondering if it would be possible to develop an Oracle adapeter un a
> resonable amount of time.
> The Postgresql adapter should generate SQL statements pretty close to=
 what
> we want in Oracle except for some types and some date formats.

Yes, it should be pretty straightforward. In fact I wrote the
AbstractDBAPI2AdaptorLayer after the whole postgresql layer was written,
just before deriving the mysql adaptor. The underlying goal was to
gather all the code for DB-APIv2-compliant python-adaptors in a single
place, letting only the details go in the specific layers (dsn, for exa=
mple).

> Are there any hidden glitches that I should be aware of ?

Hopefully there's no *hidden* glitches, or some docstrings should be
updated!

  First, you'll hopefully find all the necessary details for deriving
  AbstractDBAPI2AdaptorLayer in the docstrings ; if something is missing
  or unclear, please tell me (for example, AbstractAdaptorChannel fails
  to tell that the only method that must be overridden is
  primaryKeysForNewRowsWithEntity() --corrected in CVS).

Log msgs should be issued via the Modeling.logging.db_* methods
(db_trace, db_debug, etc.)

  If you need to add some specific types, you'll need to create a new
  Oracle9iSQLExpression and override valueTypeForExternalTypeMapping() =
as it
  is done for postgres or mysql (if you do, override
  Oracle9iAdaptor.defaultExpressionClass() as well). However for a first
  try the default (Modeling.SQLExpression) should be okay.

> except for some types and some date formats.

What do you mean by 'date formats' ?? For the moment being there's no
particular processing of dates. Within the framework we use mxDateTime,
and the conversion from/to the values in the DB is done by the
underlying python-adapters. But maybe I'm misunderstanding your point
here.


  Last, after writing, say, Oracle9iAdaptorLayer, you'll probably be ea=
ger
  to test it. The tests suite is ready for that: both tests
    test_EditingContext_Global.py and
    test_EditingContext_Global_Inheritance.py
=20=20
  take the '-d' option --given that you turn the line in their main()
  which says:

         if v not in ('Postgresql', 'MySQL'): usage(me, 1)

  into, e.g.:

         if v not in ('Postgresql', 'MySQL', 'Oracle9i'): usage(me, 1)


Well, this message looks like the beginning of an howto that should have
been already written ;)


    Anyway, if you find some time to derive the Oracle9iAdaptorLayer
    I'll be happy to help you with the details and it will be welcome in
    the DatabaseAdaptors!


> The design is pretty clean, really nice work here !

Thanks, but keep in mind that a good part of the architecture/design of
the whole framework is directly inspired/taken from the EOF's public
API, hence you can thank as well the former genious-nextstep-team who
did it!

        Regards,

-- S=E9bastien.

[Modeling-users] [Core] Release 0.8.5 / Important bug-fixes

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

        Hi all,

  Most of the changes included in this release are bug-fixes.

  The most important one adresses a bug which was defeating the uniquing
  principle of EditingContext when inheritance is involved ; this is
  demonstrated in:
    test_EditingContext_Global.test_05b_toOneFault_uniquing()

  !!! Users using inheritance are strongly advised to upgrade their
      copy, or they will certainly be bitten by this nasty bug. It
      causes very strange behaviour, such as an updated object A being
      modified when accessed from object B but left unmodified when
      accessed from object C.

      (Thank you SoaF for reporting this!)

  Note: this bug is only triggered by a given sequence of events, when
        different relationships point to different entities which are
        parents/children.

  Other changes are detailed in the changelog and are included at the
  end of the message.


About the near future:

  We are on our way to public v0.9, which has already been put in
  production for more than 3 months now and is considered stable. V0.9
  is still planned for the end of the week (it might be late a week,
  though). One or two minor releases will probably be necessary before =
0.9.


        Regards,

-- S=E9bastien.


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

0.8.5 (2003/02/10)
-----

  * EditingContext:

    - added: exception ObjectNotRegisteredError
             now raised by: deleteObject()

    - added: allInsertedObjects(), allUpdatedObjects, allDeletedObjects=
()
             see docstrings for details

    - implemented: arrayFaultWithSourceGlobalID()

    - UniquingTable: added support for ``root GlobalID'', and fixed
      addObjectForGlobalID(), forgetObject(), forgetObjectForGlobalID(),
      hasObject(). This fixes the following bug: when a relationship to
      an entity having a parent entity was triggered, it was possible to
      get a fault instead of the real object (when that object was
      already set).
      Cf. test_EditingContext_Global_Inheritance.test_05b_toOneFault_un=
iquing
      for more detail


  * Relationship.SimpleRelationship:

    - validateValue(): validation of a value being a fault now
      immediately succeeds and returns. We do not want to trigger faults
      when validating the values, faults are considered okay wrt. the
      validation logic.

    - setMultiplicityUpperBound() now accepts '*' for -1 (unconstrained
        toMany relationships)


  * ObjectStoreCoordinator:

      - fixed arrayFaultWithSourceGlobalID() which was not returning any
        value

      - Followed the change in the ObjectStore API: now implements
          ownsObjects() instead of handlesObject().

      - Misc: fixed a typo in saveChangesInEditingContext()/error
          msg. when changes are rolled back"
          Modeling/ObjectStoreCoordinator.py


  * QualifierParser.qualifierWithQualifierFormat: now allows upper-case
      for the first character in a key (e.g. "AGE =3D=3D NULL")
      (see also test_Qualifier.test_07_qualifierWithQualifierFormat4)

  * GlobalID: fixed KeyGlobalID.keyValues(): was returning the internal
      dictionary, making it possible to inadvertently change its
      read-only state.

  * Entity: Added: (module) primaryKeyForGlobalID()
                   (class)  primaryKeyForGlobalID() and primaryKeyForRo=
w()
           +Some docstrings now uses utils.finalize_docstrings

  * Adaptor: Added CannotSerializeException. adaptorWithName() now
      includes the traceback in the message of exception
      AdaptorImportError when an adaptor cannot be loaded'

  * tests: fixed test_Model.py (could not run individually, missing imp=
ort)

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

[Modeling-users] Oracle DB Adapter

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I took a quick look at the MySQL and Postgresql adapters and I'm
wondering if it would be possible to develop an Oracle adapeter un a
resonable amount of time.

The Postgresql adapter should generate SQL statements pretty close to what we 
want in Oracle except for some types and some date formats.

Are there any hidden glitches that I should be aware of ?

The design is pretty clean, really nice work here !

Regards, 

- -- 
Yannick Gingras
Developer, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+SBzlrhy5Fqn/MRARAkw4AJsF7tUMZ3Wm16vJnT+vReEbIB7F2QCgkW4a
RA6QXnuHgzXN4Sr0DA+8ic4=
=fNk6
-----END PGP SIGNATURE-----

Re: [Modeling-users] MySQL Adapter

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

        Hi,

> Hi,=20
>   I'd like to know what I should put in the ZModeling interface, in
> the field "adaptorName" to use a MySQL database.
>=20
> I tried "Modeling.DatabaseAdaptors.MySQLAdaptorLayer.MySQLAdaptor",
> "Modeling.DatabaseAdaptors.MySQLAdaptorLayer.MySQLAdaptor.MySQLAdapto=
r",
> "DatabaseAdaptors.MySQLAdaptorLayer.MySQLAdaptor",
> "DatabaseAdaptors.MySQLAdaptorLayer.MySQLAdaptor.MySQLAdaptor",
> "MySQLAdaptorLayer.MySQLAdaptor.MySQLAdaptor",
> "MySQLAdaptorLayer.MySQLAdaptor", and "MySQLAdaptorLayer".
>=20
> When I validate my model I alway have 2 warnings :=20
>    - adaptorName 'NameOfAdaptor' is not one of the framework's, maybe=
 one of=20
> yours
>    - Couldnt find concrete Adaptor for 'NameOfAdaptor'
>=20

  This is described in the User's Guide paragraph 2.2.2.,
  cf.http://modeling.sourceforge.net/UserGuide/model-props.html

      adaptorName: the name of the database-adaptor, i.e. back-end, you
          want to use for the entities in the model. Currently only
          Postgresql and MySQL (exact typo.) are valid adaptorNames ;
          the former corresponds to the package PostgresqlAdaptorLayer,
          the latter, to package MySQLAdaptorLayer.
=20=20=20=20=20=20
  But okay, I agree this could be stated as well on the TTW interface,
  if it was you would not have been bitten... Sorry for that, I'll add
  this hint in the next release. However when designing a model you
  might find it useful to keep an eye on the UserGuide's section 2.2
  which describes the xml-format, since everything found there can be
  applied to every single parameter exposed in the ZModeler.

> I'm a bit clueless right now, what are the legal adaptor names in the
> ZModeling interface ?

  Postgresql and MySQL are the 2 legal adaptor names for the moment. For
  the curious, you were heading in the right direction when trying to
  feed it with the name of the package ; you were just unlucky |: legal
  names are derived from DatabaseAdaptor's package names with
  'AdaptorLayer' omitted, hence: Postgresql and MySQL.

        Regards,


-- S=E9bastien.

[Modeling-users] MySQL Adapter

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi, 
  I'd like to know what I should put in the ZModeling interface, in
the field "adaptorName" to use a MySQL database.

I tried "Modeling.DatabaseAdaptors.MySQLAdaptorLayer.MySQLAdaptor", 
"Modeling.DatabaseAdaptors.MySQLAdaptorLayer.MySQLAdaptor.MySQLAdaptor",
"DatabaseAdaptors.MySQLAdaptorLayer.MySQLAdaptor",
"DatabaseAdaptors.MySQLAdaptorLayer.MySQLAdaptor.MySQLAdaptor",
"MySQLAdaptorLayer.MySQLAdaptor.MySQLAdaptor",
"MySQLAdaptorLayer.MySQLAdaptor", and "MySQLAdaptorLayer".

When I validate my model I alway have 2 warnings : 
   - adaptorName 'NameOfAdaptor' is not one of the framework's, maybe one of 
yours
   - Couldnt find concrete Adaptor for 'NameOfAdaptor'

I'm a bit clueless right now, what are the legal adaptor names in the 
ZModeling interface ?

Regards, 

- -- 
Yannick Gingras
Developer, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+R9ZFrhy5Fqn/MRARApq5AJ9kf9BhOFvRukpC75OP11w1e0Ys1wCdGFgu
nSkpBVodZrjI5O8ZhjboBhk=
=xQ/A
-----END PGP SIGNATURE-----

[Modeling-users] Modeling-Core v0.8.4 released

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

        Hi all,

  On the way to have the ZModeler's features available on the command-l=
ine,
  here is version 0.8.4. This release includes a new script:
  mdl_generate_python_code.py which unsurprisingly generates python-cod=
e from
  an xml-model.

    Please also note that the two others scripts, generate_DB_schema and
  validate_model are renamed to resp. mdl_generate_DB_schema and
  mdl_validate_model to avoid name clashes --btw 'mdl' stands for model=
ing.

        Have fun!

-- S=E9bastien.

Re: [Modeling-users] Installation tests failure (datetime) - osx, pypgsql

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

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

> However, it also makes me ask why does the XML model include the
> adaptorName and connectionDictionary attributes?  These are specifying
> mysql or postgres... so the rest of the model defn should comply? I
> know, it should be independent, but then also both these attributes
> should not appear here (in any case they make the model, as is, not
> portable).

Okay, I see what you mean, but from a practical point of view
Entity-Relationship Models are always dependent to the underlying
database (one example: the supported sql datatypes vary from on backend
to another).

However, there is one prominent reason for having connection
dictionaries within each model. Connection dictionaries act like
identifiers for databases. At runtime, when the core manages two (or
more) models it needs to know whether they are in the same database ; if
they do, both models shares the same architecture (caching, etc.), if
they don't, they won't! More precisely, that means sharing (or not
sharing) the database layer (made of Database, DatabaseContext and
DatabaseChannel) and the Adaptor Layer (made of Adaptor, AdaptorContext
and AdaptorChannel). Hence, a model needs to be, and actuall is,
strongly bound to the db's conn.dict. at runtime, therefore it is
included in the model. BTW that's not the only way to go, agreed.

> >> Evaluating: DROP TABLE WRITER
> >> Couldn't evaluate expression DROP TABLE WRITER. Reason:
> >> libpq.OperationalError:ERROR:  Cannot drop table writer because ot=
her
> >> objects depend on it
> >>          Use DROP ... CASCADE to drop the dependent objects too
> >
> > Although logical, that's amazing, I never get this with postgres
> > 7.2.1. I've to check that, and see if I can find a common
> > behaviour. If someone as any hints about this, please share!
>=20
> No ideas, but why is it logical?

Postgresql v7.3 just refuses to drop a table when referential
constraints are attached to it (except when instructed to 'cascade' the
delete --unsupported feature in v7.2). I suspect this has to do this the
fact that deleting referential constraints is a childish on 7.3 --for
7.2 see http://www.freebsddiary.org/postgresql-dropping-constraints.php
Not exactly straightforward, humm?!!

-- S=E9bastien.

Re: [Modeling-users] (LONG) Other OR-bridges?

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

        Hi,

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

> Ah, very good to have the script. Also the tutorial.
> If you like I can review the tutorial, as well the the other docs...

  If you have some time to review some of the documentations your
  comments and changes will for sure be greatly
  appreciated. Documentation is unfortunately not what I do best, and
  I'm afraid my english is not that good.

> Yes, it is there, but it reads more like a brief overview of main
> elements and attributes, leaving one wondering what the complete
> picture is.  Having the XML spec available will take off the pressure
> on the general explanation, allowing it to highlight only what is
> typically most pertinent and not get lost in detail.  The XML spec
> could be its XSD (although i'd prefer another more expressive (human)
> definition syntax... in any case, it should only be up to half a page
> long.

  Hopefully you will find the changes of some interest. I re-organized
  and rewrote part of chapter 2, the xml format is now fully
  documented. The description I made of the XML format is naive, but I'm
  not familiar with XML specification at all.

> Also, I do not think that validation of the XML (per se) would be
> particularly useful, as it would not imply much about how valid the
> represented model is anyway.

Agreed

> > I can't see precisely how to design a csv that maps nicely to the x=
ml,
> > but I'm open to suggestions! Same, anyone feeling like coding some=
=20
> > tools
> > will be welcome ;) and in that case, I'll start a dev-branch and sh=
are
> > the unreleased-coz'-unfinished code I already have.
>=20
> CSV may or may not be appropriate, given that you do have some nesting
> in your format. However, after I familiarize myself better with the
> schema, I could offer something more concrete. On this issue, another
> possibly interesting way to handle this "description language" is
> using a construct or mini language in python itself...

Here again, feel free to share your ideas ;) I've been working on this
for such a long time that it is difficult to get fresh new ideas.

[...]
> >> Again, cost of fetching is (much) less important here. In addition,
> >> normally data is modified in small units, typically 1 object at a
> >> time. But when browsing, it is common to request fetches of 1000s =
of
> >> objects...
> >
> > That's exactly why there should be the possibility to fetch and get=
 raw
> > rows, not objects.
>=20
> There isn't? But can always do a raw select...

Right. I meant a mean to fetch raw rows and then easily get (a subset o=
f)
corresponding objects within the framework. BTW, this is possible, but
undocumented... I'll check that tomorrow and a FAQ entry ; remind me of
that if I forget!

> Do not know if this is already there, but i guess it would be also
> useful to be able to simply request to force a fresh fetch -- if any
> of the objects are already in the store they are reloaded.

This is part of the current dev. effort and will be present in v0.9.

> [about pessimistic locking] In general I am wary of this kind of
> behaviour as (a) it probably increases the possibility of clashes and
> "deadlocks", as mentioned in the linked article and (b) it is heavier
> on the server and (c) more difficult to program for, and introduces an
> additional set of possible problems, e.g. what if, after the
> application, after acquiring a lock on some objects, runs into
> problems and never gives it up?  Bad programming? Maybe, but the
> program should not have to worry about this.

That's my point of view too, and for this reason pessimistic locking is
surely not on top of the list (optimistic locking is, btw).

> Also, on requiring an object to be modified by only one person at a
> time -- this can always be handled with the mechanism described above,
> namely that before committing a change, the "original" object is
> compared to the db object, and if different the error is raised (and
> may be ignored). Besides, when would such a case require this? Aside,
> even systems like CVS do not restrict that a co item be modified by
> only one person.

Know what? I have never worked on any applications that did require
pessimistic locking. But you can find it documented in many books or
articles --I would be very interested in hearing from projects where it
was/is required!

> Hey, my interest in Modeling is based on what it does, and how it does
> it...  But, as i mentioned above, it would help it if all that it
> actually does already is given more prominence...

Sure, and again, thanks for your comments which should /normally/ help
in achieving that goal! If you feel like making some changes on your
own, I'll be happy to grant you write-access to cvs, just email me
privately and we'll set this up.

        Regards,

-- S=E9bastien.

[Modeling-users] [Core] Release 0.8.3

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

        Hi all,

  The Modeling's core v0.8.3 has just been released.

  It contains a rewrite of the UserGuide's Chapter 2. Defining a model
has been rewritten. The subject of this chapter is not centered on the
ZModeler anymore, rather it provides a full description of the
xml-format used to define a model.

  Additionally a new command-line python script 'validate_model.py' has
been added. It is now possible to validate a model apart from the
ZModeler.

-- S=E9bastien.


------------------------------------------------------------------------
0.8.3 Changelog
---------------

  * User Guide / Chapter 2. Defining a model rewritten. The subject of =
this
    chapter is not centered on the ZModeler anymore, rather it provides=
 a full
    description of the xml-format used to define a model.

  * Reorganized the directory Modeling/doc/

  * Added: scripts/validate_model.py

    ModelValidation.ModelValidationException: API change: added has_err=
ors()
    and levels_of_errors()

Re: [Modeling-users] Core v0.8.2 released

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

Mario Ruggier <ma...@ru...> writes:
> But, build (and install) fails:
> error: file 'Modeling/scripts/generate_DB_schema.py' does not exist

Ok, I ``just'' forgot to include it in the tarball |8>-

--> You'll find 0.8.2.1 on sourceforge containing the announced scripts/
    directory.

  Sorry for the inconvenience.

-- S=E9bastien.