[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Mon May 5 11:00:00 2008 UTC to Tue May 6 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Mon May 5 20:56:21 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009505.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Mon May 5 20:57:51 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009506.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Mon May 5 20:59:22 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009507.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Mon May 5 21:00:52 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009508.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Mon May 5 21:02:23 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009509.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Hey,
Laurence Rowe wrote:
See pypi or the readme for details, but briefly usage is something like:
engine = create_engine('sqlite:///')
Session = scoped_session(sessionmaker(
... bind=engine, transactional=True, autoflush=True,
... extension=ZopeTransactionExtension()))
session = Session()
session.save(User(name='bob'))
transaction.commit()
One thing I understood from Christian Theune is that with scoped
sessions, explicit session.save() is not always necessary. Since I see
it being used here, could you perhaps comment on this?
This is great news, also for megrok.rdb, which we started to develop at
the Grokkerdam sprint.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] mysqldbda bloats zodb
Silence is consent. Fix is ready and tested. I'll go ahead and fix this. Monday, May 5, 2008, 6:57:24 PM, you wrote: AG Hello, AG I'm digging again around rdb and friends. AG It seems now that mysqldbda bloats zodb in AG def _connection_factory(self): AG Create a MySQLdb DBI connection based on the DSN AG ... AG self.__stringConverter = AG MySQLStringConverter(self.getEncoding()) AG return connection AG on almost every request of us. That causes plenty of conflict errors I AG guess. But strangely we end up with AG ConnectionStateError: Shouldn't load state for 0x24 when the connection is closed AG (0x24 is the MySQLdbAdapter instance) AG So, I would move the assignment of __stringConverter to setEncoding AG where it belongs. (Change it only when the encoding changes). AG This seems to solve the above errors. AG Any objections? -- Best regards, Adam GROSZERmailto:[EMAIL PROTECTED] -- Quote of the day: A professor is one who talks in someone else's sleep. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Laurence Rowe wrote: I've uploaded it to zope svn and pypi. See http://pypi.python.org/pypi/zope.sqlalchemy Another comment: Could you please use proper release numbers instead of the 0.1dev-r86482 stuff? And follow the official release procedure, which doesn't seem to be actually published on the web outside of grok.zope.org: http://grok.zope.org/documentation/how-to/releasing-software I realize that the package is very young, but I'm saying this for a reason; while doing it quickly seems convenience we've had a lot of troubles in the past building on such quick dirty releases. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.sqlalchemy
On Tue, May 06, 2008 at 02:26:58AM +0100, Laurence Rowe wrote: Any comments appreciated. It looks very, very good. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Somebody needs to talk at EuropPython.
So, we need talks at EuropPython about both Repoze and Grok. I can't go, but I want to make sure *somebody* does. :) Hands up: Who is talking about Grok, and who talks about Repoze? :) Other super-cool Zope technologies that should be talked about? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Martijn Faassen wrote: Laurence Rowe wrote: I've uploaded it to zope svn and pypi. See http://pypi.python.org/pypi/zope.sqlalchemy And yet another setup.py comment: the 'url' section right now points to http://svn.zope.org/zope.sqlalchemy'. I'm not sure, but I thought we had a policy not to use our SVN as the homepage URL in setup.py. Comments from others please? Regards, Martijn P.S. sorry for all the criticisms, they're intended to be constructive. I'm very excited this project is going ahead. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Repoze-dev] Somebody needs to talk at EuropPython.
I can't go either. If anyone wanted to give a talk, they'd be welcome to use my repoze.zope2 slides at http://plope.com/static/presentations/repoze-zope2-pycon-2008.pdf (I also have it in Keynote format as necessary). - C Lennart Regebro wrote: So, we need talks at EuropPython about both Repoze and Grok. I can't go, but I want to make sure *somebody* does. :) Hands up: Who is talking about Grok, and who talks about Repoze? :) Other super-cool Zope technologies that should be talked about? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Martijn Faassen wrote:
Hey,
Laurence Rowe wrote:
See pypi or the readme for details, but briefly usage is something like:
engine = create_engine('sqlite:///')
Session = scoped_session(sessionmaker(
... bind=engine, transactional=True, autoflush=True,
... extension=ZopeTransactionExtension()))
session = Session()
session.save(User(name='bob'))
transaction.commit()
One thing I understood from Christian Theune is that with scoped
sessions, explicit session.save() is not always necessary. Since I see
it being used here, could you perhaps comment on this?
Registering a mapper with Session.mapper would work with this extension,
but I'm reluctant to recommend it for two reasons: I don't know how it
works with the declarative plugin; and it necessarily limits mapped
classes to a single Session and therefor a single engine. In a zope
context I think it's quite likely that you could have the same classes
mapped to different databases (i.e. two instances of a single application).
This is great news, also for megrok.rdb, which we started to develop at
the Grokkerdam sprint.
I read somewhere on one of the blog planets that you had discussed
container implementations. Any more information/code about this? I'm
quite hopeful that Zope 2.12 will let us share much more code now that
Acquisition is being tamed.
Laurence
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sqlalchemy
On May 6, 2008, at 12:14 PM, Laurence Rowe wrote: Martijn Faassen wrote: One thing I understood from Christian Theune is that with scoped sessions, explicit session.save() is not always necessary. Since I see it being used here, could you perhaps comment on this? Registering a mapper with Session.mapper would work with this extension, but I'm reluctant to recommend it for two reasons: I don't know how it works with the declarative plugin; and it necessarily limits mapped classes to a single Session and therefor a single engine. In a zope context I think it's quite likely that you could have the same classes mapped to different databases (i.e. two instances of a single application). hi there - a little background on the save_on_init option of Session.mapper. This behavior has its roots way back in SQLAlchemy 0.1, when there was no Session or Query or anything like that, and objects, when instantiated, went directly to a thread-local registry automatically. When SQLA 0.2 came out, we introduced all the additional constructs like Session and such which are familiar today, but extensions were provided which, when enabled, would re-enable the 0.1 behavior of everything threadlocal/automatic in a similar way. Ultimately thats where Session.mapper comes from. Like all typing-savers, save on init by then was used by dozens of Pylons users who swore by it and would scream and yell at any hint of removing this already legacy feature. At the same time, new users who were using Pylons tutorials (and therefore save_on_init, without really knowing it) in conjunction with creating their own Session objects were baffled by error messages like object X is already in session Y. By the time 0.4 came out, we had started automating Session a lot more, adding autoflush capability to it. This feature immediately had issues with save_on_init for this reason: class MyClass(object): def __init__(self): self.some_variable = session.query(Foobar).filter(xyz).one() Where above, the query(Foobar) would fire off autoflush, MyClass would be flushed, and then an IntegrityError would be raised since MyClass would be missing some necessary state. Changing save_on_init to fire off *after* __init__ was a possibility there but then other things could break. So I've already not liked save_on_init for a couple of years due to its inherent intrusiveness, and because SA historically does not like being in the business of providing framework features (though we have decided to stay in that arena to some degree with declarative and scoped_session). The Session.mapper feature is stressed a whole lot less in the 0.4 docs, and as I work on the 0.5 docs this week I'm feeling very much like I'm going to remove it from the main documentation altogether. We''re consolidating the save/update/save_or_update names into just add() and add_all(), so explicitly adding items to a Session should be a more pleasant experience which I wouldn't want anyone to miss. The aspect of Session.mapper which is somewhat reduntant vs. declarative is that they both want to add an automatic __init__(**kwargs) method which assigns all given keyword values to the instance.They are not incompatible because Session.mapper only adds an __init__ if none is available already. The final feature of Session.mapper which is more reasonable is the query attribute. This feature allows you to say: MyClass.query as an equivalent for session.query(MyClass). For that specific attribute, instead of using Session.mapper, its functionality has been exported into its own descriptor-producing method, like so: class MyBaseClass(object): query = Session.query_property() So this is a way to get that one aspect without buying into the Session.mapper thing. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Repoze-dev] Somebody needs to talk at EuropPython.
Lennart Regebro wrote: So, we need talks at EuropPython about both Repoze and Grok. I can't go, but I want to make sure *somebody* does. :) Hands up: Who is talking about Grok, and who talks about Repoze? :) Other super-cool Zope technologies that should be talked about? I think Lennart is really hitting a nail here. We need to advertize about our great efforts. I wont be in EuroPython even if I would have spoken about it with pleasure. -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Laurence Rowe wrote: [snip] This is great news, also for megrok.rdb, which we started to develop at the Grokkerdam sprint. I read somewhere on one of the blog planets that you had discussed container implementations. Any more information/code about this? I'm quite hopeful that Zope 2.12 will let us share much more code now that Acquisition is being tamed. Our sketchy code is in grokapps/rdbexample. The 'megrok.rdb' is a package in there right now. It's all cobbled together in unpolished form for the time being. We just basically reuse the mapping implementation SQLAlchemy already offers and give it an IContainer interface. It's not done yet but it's a large part of the solution. I'm writing a report on the grokkerdam sprint, but it isn't out yet. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zope.sqlalchemy
Hey Michael, Thanks for the input! Michael Bayer wrote: [snip] So I've already not liked save_on_init for a couple of years due to its inherent intrusiveness, and because SA historically does not like being in the business of providing framework features (though we have decided to stay in that arena to some degree with declarative and scoped_session). I'll try to summarize the discussion so I can find out whether I understand it. Basically you're saying you don't think save on instantiation is a good idea generally, and that we should be using session.save(). This is going to be changed to session.add() in the future. What would session.add_all() do? This ties into the mapper feature, which also offers other features. The one feature that will remain but in a new shape, without the mapper, is the ability to do MyClass.query. Is that a correct summary? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sqlalchemy
Hi, On Tue, May 06, 2008 at 12:53:05PM -0400, Michael Bayer wrote: On May 6, 2008, at 12:14 PM, Laurence Rowe wrote: Martijn Faassen wrote: One thing I understood from Christian Theune is that with scoped sessions, explicit session.save() is not always necessary. Since I see it being used here, could you perhaps comment on this? Registering a mapper with Session.mapper would work with this extension, but I'm reluctant to recommend it for two reasons: I don't know how it works with the declarative plugin; and it necessarily limits mapped classes to a single Session and therefor a single engine. In a zope context I think it's quite likely that you could have the same classes mapped to different databases (i.e. two instances of a single application). hi there - a little background on the save_on_init option of Session.mapper. This behavior has its roots way back in SQLAlchemy 0.1, when there was no Session or Query or anything like that, and objects, when instantiated, went directly to a thread-local registry automatically. When SQLA 0.2 came out, we introduced all the additional constructs like Session and such which are familiar today, but extensions were provided which, when enabled, would re-enable the 0.1 behavior of everything threadlocal/automatic in a similar way. Ultimately thats where Session.mapper comes from. That's interesting, thanks for the heads-up. For some reason I didn't hit that and was quite happy with save on init (I obviously only use one database at a time ...) but the reasons and concerns given tell me that our core transaction integration shouldn't force this onto people and we might not want to use it for grok at all. In fact at the sprint we discussed the similarities and differences of RDB versus ODB and found that the step of 'add an object to the db' is actually two functions (in one gesture) in the ODB: relate object B to object A and, therefore add it to the same database as object A is in. Whereas (due to the mapping of classes to tables) in RDB we only need to tell which database to go to. Those are similar but differen gestures and I'm not sure we had a definitive result when discussing this. Christian -- gocept gmbh co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: New i18n locale extraction concept
Christian Zagrodnick, on 2008-05-01: On 2008-05-01 02:06:17 +0200, Roger Ineichen [EMAIL PROTECTED] said: What does this mean? The locale extraction is now a part of a recipe and not a part of a package itself. My goal is to remove the dependencies in the z3c.recipe.i18n, because right now it uses the base implementation in zope.app.locales which makes it depend on the hole zope namepsace. Because of the overall zope.* dependenc in zope.app.locale. Actually, there is lovely.receipe:i18n which provides i18n extraction. Does z3c.recipe.i18n something else or why is there yet another i18n recipe? For me a downside of lovely.recipe:i18n is that it has too many dependencies: the whole of zope. When easy installing it in a virtual env, you end up with 44 MB of eggs. For comparison, easy installing i18ndude needs about 6 MB. See this (currently) small thread in grok-dev: http://thread.gmane.org/gmane.comp.web.zope.grok.devel/4742 -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ This is your day, don't let them take it away. [Barlow Girl] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: zope.sqlalchemy
On May 6, 2008, at 5:24 PM, Martijn Faassen wrote: Hey Michael, Thanks for the input! Michael Bayer wrote: [snip] So I've already not liked save_on_init for a couple of years due to its inherent intrusiveness, and because SA historically does not like being in the business of providing framework features (though we have decided to stay in that arena to some degree with declarative and scoped_session). I'll try to summarize the discussion so I can find out whether I understand it. Basically you're saying you don't think save on instantiation is a good idea generally, and that we should be using session.save(). This is going to be changed to session.add() in the future. What would session.add_all() do? session.add_all() is just: session.add_all([obj1, obj2, obj3, ...]) Also session.save()/update/save_or_update will remain throughout 0.5 at least. This ties into the mapper feature, which also offers other features. The one feature that will remain but in a new shape, without the mapper, is the ability to do MyClass.query. Is that a correct summary? Session.mapper and save_on_init has no plans of going away in 0.5, but I plan to de-emphasize it.The query descriptor function is also available in 0.4. - mike ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
