Re: [Zope3-Users] searching and relations

2006-07-23 Thread Darryl Cousins
Gary Poster wrote:
 If the relationship is intrinsic to one object's data model but not  
 to the other's, then it makes sense to have a Python pointer on the  
 first object. 

Hi Gary,

Am I right that 'a Python pointer on the first object' is defined by
simply defining the schema field, eg::

mypointer = Object(
title=Pointer to object,
schema=IInterfaceOfTheTarget)

Then everything else will fall into place. I could even use formlib to
edit the object being pointed to from within a form editing the 'first
object'. 

The second object would not even know it is pointed to. For it to know I
would need to use a relationship as you go on to discuss.

Have a correctly understood?

Regards,
Darryl

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


Re: [Zope3-Users] searching and relations

2006-07-23 Thread Gary Poster


On Jul 23, 2006, at 4:12 AM, Darryl Cousins wrote:


Gary Poster wrote:

If the relationship is intrinsic to one object's data model but not
to the other's, then it makes sense to have a Python pointer on the
first object.


Hi Gary,

Am I right that 'a Python pointer on the first object' is defined by
simply defining the schema field, eg::

mypointer = Object(
title=Pointer to object,
schema=IInterfaceOfTheTarget)

Then everything else will fall into place. I could even use formlib to
edit the object being pointed to from within a form editing the 'first
object'.

The second object would not even know it is pointed to. For it to  
know I

would need to use a relationship as you go on to discuss.

Have a correctly understood?


Yes, precisely; and for what it is worth, the Object schema value  
lets formlib work, and specifies part of your software's contract,  
but is not necessary for the most basic story.  The simplest clear  
case (Where `app` represents some ZODB folder, like the application  
root):


class DemoSubject(persistent.Persistent):
pass

class DemoObject(persistent.Persistent):
pass

app['demo'] = DemoSubject()
app['demo'].mypointer = DemoObject()

By the way, a small but possibly important subtlety about the object  
widgets that are associated with the schema object fields is that  
(unless you manage your form pretty carefully) they change value by  
creating new instances of the sub-object and replacing it on the main  
object, not by modifying an old sub-object instance, IIRC.


Sometimes Choice fields with a custom vocabulary or source are what  
you want, if you want to make a pointer to an object that already  
exists somewhere in the database.


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


Re: [Zope3-Users] searching and relations

2006-07-22 Thread Lorenzo Gil Sanchez
El vie, 21-07-2006 a las 10:21 -0400, Pete Taylor escribió:
 Lorenzo,
 I've run into a very (very!) similar situation, and ended up writing
 some wrapper/simplification utilities for zc.relationship.
 zc.relationship is wonderfully powerful, but a bit complex.  It's use
 is intuitive once you wade through the 2000+ lines of documentation
 (which is worthwhile reading), but it's a bit intimidating at first.

Ok, I was afraid of an answer like this because in a recent thread I've
read Jim Fulton saying that we are trying to use zodb as a relational
database which is a shame and I think I agree with that quote.

So that's why I tried not to use external packages like zc.relationship
and stick to a plain object model with intrinsic relations modeled as
simple object attributes. The obvious question is: does this allow
powerful queries like the ones I mentioned in my first email or I should
switch and use extrinsic relations for this kind of features?

 
 I've packaged up my wrapper utilities as a product, and ZPL2.1'd the
 code.  If you'd like it, even just for reference, let me know.  I
 intend to release it more publicly shortly.

Sure! I'm 120% interested in reading your solution since reinventing the
wheel is something I always try to avoid. Thanks a lot for you kindly
offer!

Lorenzo

   It implements nice
 adapters, so objects implementing a particular marker interface can do
 things like:
 
 client = MyClient()
 q = IQuestion(obj)
 orders = q.ask_as_subject(owns)
 orders
 ['some.Order object at...']
 
 you can also build filter functions that take the relationship you're
 targeting as an argument, and check any property of the relationship
 in question...
 
 let me know if you'd like a copy.  if not, then i'd suggest going
 through at least the containers.txt in zc.relationship.
 
 as far as the catalog goes, i'd get into using hurry.query as fast as
 possible ;)
 
 On 7/21/06, Lorenzo Gil Sanchez [EMAIL PROTECTED] wrote:
  Hi,
 
  I've been following recent discussion about relations in Zope. Both
  intrinsic and extrinsic relationships.
 
  For the following question lets assume we have a IClient and an IOrder
  content types and the IOrder schema has a IClient attribute called 'client'.
 
  Reading previous messages to this list I understand that's the best way
  to model this kind of intrinsic relationship between an Order and a Client.
 
  Now the question: using a Catalog, what should I do to answer these kind
  of questions:
 
- Give me all orders whose client's name starts with 'John'
 
- Give me all orders whose client's age is between 20 and 30
 
- Give me all orders for a certain client
 
  I guess I need to use a special kind of FieldIndex for objects but I'm
  new to the Catalog land and I'm pretty much lost.
 
  Any help, examples or pointers to detailed doc are greatly appreciated :-)
 
  Best regards,
 
  Lorenzo Gil
  ___
  Zope3-users mailing list
  Zope3-users@zope.org
  http://mail.zope.org/mailman/listinfo/zope3-users
 
 
 

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


Re: [Zope3-Users] searching and relations

2006-07-22 Thread Gary Poster


On Jul 22, 2006, at 4:47 AM, Lorenzo Gil Sanchez wrote:


El vie, 21-07-2006 a las 10:21 -0400, Pete Taylor escribió:

Lorenzo,
I've run into a very (very!) similar situation, and ended up writing
some wrapper/simplification utilities for zc.relationship.
zc.relationship is wonderfully powerful, but a bit complex.  It's use
is intuitive once you wade through the 2000+ lines of documentation
(which is worthwhile reading), but it's a bit intimidating at first.


Ok, I was afraid of an answer like this because in a recent thread  
I've

read Jim Fulton saying that we are trying to use zodb as a relational
database which is a shame and I think I agree with that quote.

So that's why I tried not to use external packages like  
zc.relationship

and stick to a plain object model with intrinsic relations modeled as
simple object attributes.


Heh.  I gave that Jim Fulton quote, and encouraged the direction you  
describe; *and* I wrote zc.relationship. ;-)  They are not mutually  
exclusive.  Let's take a simple two-member directional relationship  
as an example--something like A depends on B.


If neither object should inherently know about the relationship--it's  
not intrinsic to either of their data models--then it makes good  
sense to have external relationship objects that model the  
connection.  The relationship container in zc.relationship is a  
simple example of a solution for that use case.


If the relationship is intrinsic to one object's data model but not  
to the other's, then it makes sense to have a Python pointer on the  
first object.  If you need to ask questions, such as simple  
backpointers, then you can set up an extrinsic reference or you can  
set up a zc.relationship index to index the first object.  For a  
simple backpointer case, an extrinsic reference is sufficient and  
simpler.  If you need more sophisticated queries than just  
backpointers then the zc.relationship index can be a real win: you  
can adapt the first object to a relationship interface that breaks  
the relationship down into parts that match the queries you want to  
make.   That works nicely.


If the relationship is intrinsic to both objects' data models, all  
you can really do is choose one of the previous two approaches and  
put some sugar around it.  AIUI, schooltool's relationship code does  
something like this: you can specify both sides of a relationship in  
a class definition (and an interface, I believe) and behind the  
scenes it keeps track of the relationship for you in an external data  
structure, no matter which side of the relationship you modify.   
zc.relationship's index could be used to build functionality like  
this, but it has not been done to my knowledge.




The obvious question is: does this allow
powerful queries like the ones I mentioned in my first email or I  
should

switch and use extrinsic relations for this kind of features?


zc.relationship indexes can be combined with other catalog indexes to  
do what you described, but doing so efficiently will require  
knowledge of catalog indexes and the BTree module.  The README for  
zc.relationship touches on this when it discusses filters:


| If relationship tokens (from 'findRelationshipChains' or 'apply' or
| 'findRelationshipTokenSet', or in a filter to most of the search  
methods) are
| to be merged with other catalog results, relationship tokens should  
be based
| on intids, as in the default.  For instance, if some relationships  
are only
| available to some users on the basis of security, and you keep an  
index of
| this, then you will want to use a filter based on the relationship  
tokens

| viewable by the current user as kept by the catalog index.

The filter is not the only approach--you will sometimes want to merge  
*results* from a relationship index and other indexes, for instance-- 
but if you are doing transitive searches it may be preferred for  
efficiency.


zc.relationship is a bit of a powertool.  Projects like the one Pete  
describes to make a friendly, more constrained usage of it will be  
very useful.


Also, don't forget SQL.  I prefer the ZODB, and stay there if I can  
make a reasonably convincing case (almost always ;-) ), but sometimes  
an app really calls out for a hybrid approach.


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


[Zope3-Users] searching and relations

2006-07-21 Thread Lorenzo Gil Sanchez

Hi,

I've been following recent discussion about relations in Zope. Both 
intrinsic and extrinsic relationships.


For the following question lets assume we have a IClient and an IOrder 
content types and the IOrder schema has a IClient attribute called 'client'.


Reading previous messages to this list I understand that's the best way 
to model this kind of intrinsic relationship between an Order and a Client.


Now the question: using a Catalog, what should I do to answer these kind 
of questions:


 - Give me all orders whose client's name starts with 'John'

 - Give me all orders whose client's age is between 20 and 30

 - Give me all orders for a certain client

I guess I need to use a special kind of FieldIndex for objects but I'm 
new to the Catalog land and I'm pretty much lost.


Any help, examples or pointers to detailed doc are greatly appreciated :-)

Best regards,

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


Re: [Zope3-Users] searching and relations

2006-07-21 Thread Pete Taylor

Lorenzo,
I've run into a very (very!) similar situation, and ended up writing
some wrapper/simplification utilities for zc.relationship.
zc.relationship is wonderfully powerful, but a bit complex.  It's use
is intuitive once you wade through the 2000+ lines of documentation
(which is worthwhile reading), but it's a bit intimidating at first.

I've packaged up my wrapper utilities as a product, and ZPL2.1'd the
code.  If you'd like it, even just for reference, let me know.  I
intend to release it more publicly shortly.  It implements nice
adapters, so objects implementing a particular marker interface can do
things like:

client = MyClient()
q = IQuestion(obj)
orders = q.ask_as_subject(owns)
orders
['some.Order object at...']

you can also build filter functions that take the relationship you're
targeting as an argument, and check any property of the relationship
in question...

let me know if you'd like a copy.  if not, then i'd suggest going
through at least the containers.txt in zc.relationship.

as far as the catalog goes, i'd get into using hurry.query as fast as
possible ;)

On 7/21/06, Lorenzo Gil Sanchez [EMAIL PROTECTED] wrote:

Hi,

I've been following recent discussion about relations in Zope. Both
intrinsic and extrinsic relationships.

For the following question lets assume we have a IClient and an IOrder
content types and the IOrder schema has a IClient attribute called 'client'.

Reading previous messages to this list I understand that's the best way
to model this kind of intrinsic relationship between an Order and a Client.

Now the question: using a Catalog, what should I do to answer these kind
of questions:

  - Give me all orders whose client's name starts with 'John'

  - Give me all orders whose client's age is between 20 and 30

  - Give me all orders for a certain client

I guess I need to use a special kind of FieldIndex for objects but I'm
new to the Catalog land and I'm pretty much lost.

Any help, examples or pointers to detailed doc are greatly appreciated :-)

Best regards,

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




--
All guilt is relative, loyalty counts, and never let your conscience
be your guide.
 - Lucas Buck, American Gothic
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users