Hello Carlo.

The implementation of the container is more or less a demonstation on how to use sqlalchemy object together with a zope container. To request an object for a zope container a name is used. In the case of sqlalchemy objects a generalization. This generalization make it possible to use any database table for the container. To have a unique name of the objects for the container I use the primary key.


This container implementation is (as you already noticed) not in use because all use cases we had until now use more special integrations.

Regards
Jürgen


Carlo Cardelli wrote:
David Pratt wrote:
Hi Carlo.

As a workaround to get objects into the db you can comment out the following lines in checkName like this:

    def checkName(self, name, container):
        if isinstance(name, str):
            name = unicode(name)
        elif not isinstance(name, unicode):
            raise TypeError("Invalid name type", type(name))

        #unproxied = removeSecurityProxy(container)
        #if not name.startswith(unproxied._class.__name__+'.'):
        #  raise UserError("Invalid name for SQLAlchemy object")
        return True

I actually worked around it as following:

<code>
    unproxied = removeSecurityProxy(container)

->      if not ISQLAlchemyContainer.providedBy(unproxied):
->          return NameChooser.checkName(self, name, container)

        if not name.startswith(unproxied._class.__name__ + '.'):
            raise UserError("Invalid name for SQLAlchemy object")
</code>

even if the 'else' case seems unused: i.e., this method is not called while adding a SQLAlchemyContainer.

Once skipped this, the process halted while adding the 'blank' object to the db: in zope.app.container.browser.adding, in the method add(), the following lines failed:

<code>
        container[name] = content
        ... one ininfluent-for-this-problem line ...
        return container[name]
</code>

Here, the last line failed because the SQLAlchemyContainer completely disregards the "name" attribute (as specified in container.txt), so retrieving data using the same name is not possible.

Maybe I could spend some time in it, but this "basic" problem leads me to some doubt about the state of the zalchemy package and its integration with Zope3.

In the mailing list archives I found some discussion about ORM problems (2-phase commit, thread support and so on) but nothing specific about zalchemy, and (as far as I can see) no "definite" solution on the sqlalchemy integration.

Could someone tell the current state-of-the-art about this, or his/her experience about integrating sqlalchemy in other ways?

Thank you in advance.

Carlo Cardelli.

_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Reply via email to