[Zope-dev] Re: Re: Zope 2.11.0c1 released

[Alexander Limi]

On Sun, 25 May 2008 04:06:36 -0700, Wichert Akkerman <[EMAIL PROTECTED]>  
wrote:



Previously Alexander Limi wrote:
On Sat, 24 May 2008 04:57:35 -0700, Andreas Jung <[EMAIL PROTECTED]>  
wrote:


>I just released Zope 2.11.0c1 in order to get the final
>release of 2.11.0 out of the door as soon as possible:
>
>

Since I didn't see a clear consensus on the Z2 interfaces thread — does
this release emit deprecation warnings for the Z2 interfaces?


Tres made that change after Andreas made the c1 release.


Ah, great — so the final release will have them. That's all I wanted to  
know, thanks Tres and Wichert!


--
Alexander Limi · http://limi.net

___
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, integration ideas

[Laurence Rowe]

Brian Sutherland wrote:

On Sat, May 24, 2008 at 09:30:18PM +0100, Laurence Rowe wrote:

Brian Sutherland wrote:

On Fri, May 23, 2008 at 11:39:39PM +0100, Laurence Rowe wrote:
We need to differentiate between the interface for session configuration 
and session usage from an application.


For session usage I think it is fairly simple. We should define an 
ISessionContext interface such that:


class ISessionContext(Interface):
def __call__():
"return a session in this context"

+lots

(I was thinking about proposing an interface called ISessionMaker doing
much the same thing)

I'm not sure what "in this context" means?
The context of this application instance. Say you have two instances of an 
application, one pointed at database A, another at database B. It is 
possible to involve both applications in a single request / transaction. 
You must be sure that you are working with the correct session.


Are the instances you are talking about persistent objects in the ZODB?


Yes, I'm assuming that the application instances live in the ZODB and 
are local site managers for this example.




A future version of collective.lead could implement an ISessionContext. 
Client code however should have a cleaner interface, a plain ISession. 
This is accessed through a lookup on the context, translated into a 
simple adapter:


def session_adapter(context):
session_context = queryUtility(ISessionContext, context=context, 

Why call queryUtility with the context keyword?


default=None)
if session_context is not None:
return session_context()

This will allow application code to do something like:

session = ISession(context)
ob = session.query(MyClass)

This really confuses me. What is the context? Does it have any meaning?
Or is it just a shorter way to write:

session = getUtility(ISessionContext)()

Does the value of context have an effect on what you get from the
ISession adaptation?
Yes, as it translates directly to the getUtility lookup. It ensures that 
lookups in /appA go to a local utility defined in /appA and lookups in 
/appB go to a local utility defined in /appB.


I've been burned by using context as a keyword to getUtility before.
When your context doesn't have a proper __parent__ pointer, the default
IComponentLookup adapter falls back to the global site manager and
ignores the local one. That causes no end of confusion and hard to debug
bugs as people will call ISession on objects with and without __parent__
pointers and then wonder why it fails.

Perhaps a more robust way is to rely on the site stored while traversing
in zope.app.component.hooks?

For example:
* appA implements ISite and has a local ISessionContext utility
* The path appA is traversed over (i.e. the url path is /appA/foo)
* queryUtility(ISessionContext) then returns the local utility from
  appA without the need to specify a "context"
  (thanks to the magic in zope.app.component.hooks)

I think the only situation where you really want to specify a "context"
for queryUtility is when you want to access a local utility registered
in /appB from a URL path like /appA/foo. That seems pretty rare and
almost broken.

You could implement a function like:

def query_session(name=u''):
return queryUtility(ISessionContext, name=name)()

That does the right thing in almost all cases (i.e. uses the closest
local site), and is much more robust.


I fear that if we rely on the site manager set during traversal, then 
applications will rely on that when looking up their session in 
application code, and it will be impossible to involve objects from 
different application instances in the same transaction.


getUtility already looks up in the global component registry if a site 
manager cannot be found in the context's parents (or where __parent__ is 
missing). I guess this concept could be extended with something like:


def session_adapter(context):
smgr = getSiteManager(context)
if smgr is getGlobalSiteManager():
smgr = None
return getUtility(ISessionContext, context=smgr)()

This would defer the bugs to the point you start working with two 
instances of an application in a single request.


I wouldn't consider accessing objects from /appA and /appB in the same 
request broken, for someone coming from a ZODB background it would seems 
quite reasonable.


Of course it would be possible to register a ScopedSession globally as 
such a utility, but more usually a local utility should be registered.

Depends what you're doing. If you are running without a ZODB, you have
mostly just global utilities.

It would be a pity if zope.sqlalchemy started to depend on the ZODB.
Wihout ZODB and zope.app.component it seems unlikely that you would be able 
to register a local utility, the idea of ISessionContext is so that you 
might be able to register a ScopedSession as a global utility too.


I very much like the idea of ISessionContext!

I'm just not sure about how you suggest using it 

Re: [Zope-dev] Zope and Storm (SQL)

[Andreas Jung]

--On 24. Mai 2008 18:51:17 +0200 Brian Sutherland <[EMAIL PROTECTED]> 
wrote:



On Sat, May 24, 2008 at 06:23:01PM +0200, Andreas Jung wrote:



--On 24. Mai 2008 17:57:17 +0200 Brian Sutherland
<[EMAIL PROTECTED]>  wrote:


On Sat, May 24, 2008 at 11:28:37AM +0200, Andreas Jung wrote:

- how do you deal with hierarchical or semi-structured data
 (e.g. SGML, XML)?


As a side note, PostgreSQL 8.3 has a native XML column type. It's fairly
basic still, but you can create indexes based on xpath queries.


Jup. Postgres already had in version 7 XML support as an add-on...but
pretty much unusable for the production


Interesting, why not?

I'm finding it incredibly useful, but then maybe my needs are very
simple.


An important functionality would be being able to modify nodes of an XML 
document in-place. Storing and querying using xpath is only one part of the 
story.


Andreas



pgp0SOqQrA6sp.pgp
Description: PGP signature
___
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 and Storm (SQL)

[David Pratt]

Hi Jurgen. Thank you for keeping this thread going. It is helpful and 
good to experiment with this further for light applications. I have not 
given much attention to storage with orm since the early days of 
sqlalchemy. There have been many improvements since then to the various 
implementations. I believe Storm may be a bit more precise as to what it 
wants to be. That translates into a bit more speed from all accounts.


Jürgen kartnaller wrote:
On Sat, May 24, 2008 at 2:24 PM, David Pratt <[EMAIL PROTECTED] 
> wrote:


Hi Jurgen. Thank you for this informative post. I am particularly
interested in how this fits into the refactoring of legacy code. I
appreciate your sharing your experiences. I also think everyone has
been paying much attention to the insight Lovely has been sharing on
scaling and efficient delivery of Zope over the past couple of years.

As a means of mapping one or more backends without changing the
logic or code with backend logic, schemas play an important role. I
can see the benefit of providing plain SQL statements since they are
clearly understood. The concern I have about not using schemas is
the loss of integration potential for the different backends using a
common pattern of mapping zope schema to xml, rdf, rdb, whatever ...
In your opinion, is this abstraction simply costing too much,
unnecessary, or a matter of application development and runtime speed.




Schemas provide the potential of mapping the object structure to other 
storage backends with different notions of persistence - so not a direct 
reference for xml to sql. As much as possible I do not want to change an 
app to use a different backend. With adaptation and classes that behave 
the same way in CA, it ought to be possible to only have to change 
import statements to different implementations of Contained, Location 
etc and generally change what you are subclassing from to persist data.


I'm not sure what you mean with schema/xml in context with SQL. You can 
still use your schema as you already do. I just wrote a CSV importer 
based on schema's together with formlib's Editform and AddForm.
The only diference you have is, that it is not possible to use 
"FieldProperty" in Storm classes.




For me, the crux of the rdb approach for legacy code is the
container, location and traversal. You have been very generous with
your examples. I am really hoping for a clearer idea of handling
Container, OrderedContainer, and Location which is prevalent in
legacy code. Overall, I can say that I quite the innovation here in
getting to a 'leaner' concept of Zope.


If you have your legacy code you have a clear definition what you need 
for your container. So it should be straight forward to implement 
IContainer and ILocated.


Yes, you are right. I'll experiment with what you have provided and see 
if I can get something basic working with the z3c.traverser package. 
BTW, I am assuming at this point that everything is registered in the 
global site manager for the app. I am not sure if it is possible to have 
a notion of local sites without the ZODB. This of course would required 
changes in legacy applications as well.



Without going too deep into this here is some code which should be usable:

class Container(Storm):
interface.implements(IContainer)
__storm_table__ = 'containers'
id = Int(primary=True)
content = ReferenceSet(id, 'Content.id')
def __iter__(self):
return self.content
def __getitem__(self, name):
item = self.content.find(Content.name == name).one()
if item is None:
raise KeyError
return item
self __setitem__(self, name, item):
item.name  = name # add namechooser things here
item.parent = self
def __len__(self):
return self.content.count()

class Content(Storm):
id = Int(primary=True)
name = Unicode()
parent = Reference(id, Container.id)


No worry about killing anyone :-) I appreciate this sketch. I believe 
Martijn and Brian were discussing a generic implementation of Container 
for the different alchemy flavors a few weeks back - an implementation 
that could live outside of these packages. It would be useful to have a 
decent generic implementation for rdb implementations. Many thanks.


Regards,
David


Don't kill me if something is wrong here, this is an untested quick hack 
to demonstrate what's possible. Also the IContainer interface is not 
fully implemented.




Regards,
David



Jürgen kartnaller wrote:

There seems to be some interest on the use of SQL databases with
Zope.

Lovelysystems is now using SQL databases as the primary storage
for their applications. We use Zope and Postgres with Storm as ORM.
The main reason for switching to SQL database were speed issues
with queries.

Here is a short sum

Re: [Zope-dev] Re: zope.sqlalchemy, integration ideas

[Brian Sutherland]

On Sat, May 24, 2008 at 09:30:18PM +0100, Laurence Rowe wrote:
> Brian Sutherland wrote:
>> On Fri, May 23, 2008 at 11:39:39PM +0100, Laurence Rowe wrote:
>>> We need to differentiate between the interface for session configuration 
>>> and session usage from an application.
>>>
>>> For session usage I think it is fairly simple. We should define an 
>>> ISessionContext interface such that:
>>>
>>> class ISessionContext(Interface):
>>> def __call__():
>>> "return a session in this context"
>>
>> +lots
>>
>> (I was thinking about proposing an interface called ISessionMaker doing
>> much the same thing)
>>
>> I'm not sure what "in this context" means?
>
> The context of this application instance. Say you have two instances of an 
> application, one pointed at database A, another at database B. It is 
> possible to involve both applications in a single request / transaction. 
> You must be sure that you are working with the correct session.

Are the instances you are talking about persistent objects in the ZODB?

>>> A future version of collective.lead could implement an ISessionContext. 
>>> Client code however should have a cleaner interface, a plain ISession. 
>>> This is accessed through a lookup on the context, translated into a 
>>> simple adapter:
>>>
>>> def session_adapter(context):
>>> session_context = queryUtility(ISessionContext, context=context, 
>>
>> Why call queryUtility with the context keyword?
>>
>>> default=None)
>>> if session_context is not None:
>>> return session_context()
>>>
>>> This will allow application code to do something like:
>>>
>>> session = ISession(context)
>>> ob = session.query(MyClass)
>>
>> This really confuses me. What is the context? Does it have any meaning?
>> Or is it just a shorter way to write:
>>
>> session = getUtility(ISessionContext)()
>>
>> Does the value of context have an effect on what you get from the
>> ISession adaptation?
>
> Yes, as it translates directly to the getUtility lookup. It ensures that 
> lookups in /appA go to a local utility defined in /appA and lookups in 
> /appB go to a local utility defined in /appB.

I've been burned by using context as a keyword to getUtility before.
When your context doesn't have a proper __parent__ pointer, the default
IComponentLookup adapter falls back to the global site manager and
ignores the local one. That causes no end of confusion and hard to debug
bugs as people will call ISession on objects with and without __parent__
pointers and then wonder why it fails.

Perhaps a more robust way is to rely on the site stored while traversing
in zope.app.component.hooks?

For example:
* appA implements ISite and has a local ISessionContext utility
* The path appA is traversed over (i.e. the url path is /appA/foo)
* queryUtility(ISessionContext) then returns the local utility from
  appA without the need to specify a "context"
  (thanks to the magic in zope.app.component.hooks)

I think the only situation where you really want to specify a "context"
for queryUtility is when you want to access a local utility registered
in /appB from a URL path like /appA/foo. That seems pretty rare and
almost broken.

You could implement a function like:

def query_session(name=u''):
return queryUtility(ISessionContext, name=name)()

That does the right thing in almost all cases (i.e. uses the closest
local site), and is much more robust.

>>
>>> Of course it would be possible to register a ScopedSession globally as 
>>> such a utility, but more usually a local utility should be registered.
>>
>> Depends what you're doing. If you are running without a ZODB, you have
>> mostly just global utilities.
>>
>> It would be a pity if zope.sqlalchemy started to depend on the ZODB.
>
> Wihout ZODB and zope.app.component it seems unlikely that you would be able 
> to register a local utility, the idea of ISessionContext is so that you 
> might be able to register a ScopedSession as a global utility too.

I very much like the idea of ISessionContext!

I'm just not sure about how you suggest using it in client code.

-- 
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 )

Re: [Zope-dev] Zope3 on Google AppEngine

[Andreas Jung]

--On 24. Mai 2008 15:44:01 +0200 Hermann Himmelbauer <[EMAIL PROTECTED]> wrote:




 I currently use
SQLAlchemy,  but it seems that transactions are managed on the RDB-level
only, which means  that the object state is not in the transaction scope.


Huh? If you use one of the integration framework for sqlalchemy-within-zope 
then SQLAlchemy is fully integrated with the Zope transaction system.


Andreas



pgpbhiBAcII26.pgp
Description: PGP signature
___
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] Zope3 on Google AppEngine

[Hermann Himmelbauer]

Am Freitag, 23. Mai 2008 18:19 schrieb David Pratt:
> Hi Jodok. I had looked at storm a while back but the zope integration
> seemed to lack any relationship with zope schemas.  I guess it is
> possible to define a zope schema that is not persisted and create the
> tables from it. It did not seem to me a good way of using CA. How are
> you managing this part of things.
>
> I Haven't worked with bigtable yet myself but assume the transactional
> semantics would be a challenge since I am not sure how quickly the data
> gets to the storage. This is interesting stuff in any case.

Very interesting, indeed. Does this mean that one can basically create classes 
that inherit from some class like persistent.Persistent and data is then 
simply stored in a RDB instead of ZODB?

What I'm curious is how transactions are managed; I currently use SQLAlchemy, 
but it seems that transactions are managed on the RDB-level only, which means 
that the object state is not in the transaction scope.

Another issue is data migration, which requires changes in the database model 
(altering tables etc.), so this might be also quite challenging.

Best Regards,
Hermann

-- 
[EMAIL PROTECTED]
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
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 2.11.0c1 released

[Wichert Akkerman]

Previously Alexander Limi wrote:
> On Sat, 24 May 2008 04:57:35 -0700, Andreas Jung <[EMAIL PROTECTED]> wrote:
> 
> >I just released Zope 2.11.0c1 in order to get the final
> >release of 2.11.0 out of the door as soon as possible:
> >
> >
> 
> Since I didn't see a clear consensus on the Z2 interfaces thread — does  
> this release emit deprecation warnings for the Z2 interfaces?

Tres made that change after Andreas made the c1 release.

Wichert.

-- 
Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
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] Zope Tests: 4 OK, 1 Failed

[Zope Tests Summarizer]

Summary of messages to the zope-tests list.
Period Sat May 24 11:00:00 2008 UTC to Sun May 25 11:00:00 2008 UTC.
There were 5 messages: 5 from Zope Tests.


Test failures
-

Subject: FAILED (failures=1) : Zope-trunk Python-2.4.4 : Linux
From: Zope Tests
Date: Sat May 24 21:06:07 EDT 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009604.html


Tests passed OK
---

Subject: OK : Zope-2.8 Python-2.3.6 : Linux
From: Zope Tests
Date: Sat May 24 21:00:04 EDT 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009600.html

Subject: OK : Zope-2.9 Python-2.4.4 : Linux
From: Zope Tests
Date: Sat May 24 21:01:35 EDT 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009601.html

Subject: OK : Zope-2.10 Python-2.4.4 : Linux
From: Zope Tests
Date: Sat May 24 21:03:06 EDT 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009602.html

Subject: OK : Zope-2.11 Python-2.4.4 : Linux
From: Zope Tests
Date: Sat May 24 21:04:37 EDT 2008
URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009603.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 )