Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-14 Thread Mail List

From: Joachim Werner [EMAIL PROTECTED]

  This is true in the ZODB, but can be complicated by acquisition. If an
  object can acquire itself, it can cause issues. Plus it becomes
  difficult to know whether objects are clones or just identical
  instances, although this can be mitigated by exposing their Python
  instance id.

 Acquisition is very cool, but it sometimes really sucks ... AFAIK you can
 easily switch it off in your own Python products. But I am still
fighting
 with only getting private variables (i.e. not acquired ones) in DTML ...

From DTML I have used 2 different methods for this:
1) dtml-with expr=object only
 .
/dtml-with

or
2) dtml-if expr=_.hostattr(object.aq_explicit('attribute')
   ...
/dtml-if

In both cases 'object' is the thing with the 'private variables' and in 2),
'attribute' is the 'variable' name.
Jeff



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-14 Thread Shane Hathaway

Joachim Werner wrote:
 
  Probably I'm daft because it is Friday night, but AFAIK ZODB and most
 OODB's
  store an object only once, keyed by its object id. The rest is just
 references
  through that oid, so objects that belong to more than one container can be
  added to all these containers and n:m relations are implemented by having
 a
  list of objects on both sides.
 
 Yes, but these references (let's call them symlinks ...) are not in the
 standard Zope. Of course it should be easy to do these things, but except
 for this from Shane I haven't seen anything so far:
 http://www.zope.org/Members/hathawsh/Symlink/index_html

Actually I was referring to the OODB-equivalent of hard links.  It's
only possible from Python products / external methods / filesystem
scripts / Zope core code, but here's how you do it:

ob = some_folder.some_child
some_other_folder.some_child = ob

In other words, if you just assign an object to have multiple parents
then it will just work.  Changes to the object will appear to occur in
both places, but really they're only occurring in one place.  This
behavior is fully persistent, works over ZEO, and ZODB won't even see
there's anything unusual.

 P.S.: Shane, have you developed Symlinks any further? I think they could be
 extremely useful. I tried out the initial release and liked it, except for
 the fact that the symlinks looked EXACTLY like real ones, so they can be
 very irritating ...

I'm not sure what to do with symlinks.  How should security be applied? 
How are they most useful?

It's neat to see it works, though. :-)

Shane

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-14 Thread Jeff

From: Joachim Werner [EMAIL PROTECTED]

  This is true in the ZODB, but can be complicated by acquisition. If an
  object can acquire itself, it can cause issues. Plus it becomes
  difficult to know whether objects are clones or just identical
  instances, although this can be mitigated by exposing their Python
  instance id.

 Acquisition is very cool, but it sometimes really sucks ... AFAIK you can
 easily switch it off in your own Python products. But I am still
fighting
 with only getting private variables (i.e. not acquired ones) in DTML ...



From DTML I have used 2 different methods for this:
1) 
dtml-with expr=object only
 .
/dtml-with

or
2) 
dtml-if expr=_.hostattr(object.aq_explicit('attribute')
   ...
/dtml-if

In both cases 'object' is the thing with the 'private variables' and in 2),
'attribute' is the 'variable' name.
Jeff




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-14 Thread Juan David Ibáñez Palomar

 
  P.S.: Shane, have you developed Symlinks any further? I think they could be
  extremely useful. I tried out the initial release and liked it, except for
  the fact that the symlinks looked EXACTLY like real ones, so they can be
  very irritating ...
 
 I'm not sure what to do with symlinks.  How should security be applied? 
 How are they most useful?
 
 It's neat to see it works, though. :-)
 
 Shane
 
 

Last year I needed symlinks and developed a version of your product
where the symlink had a different id than the real object. But the
general solution of a symlink where an arbitrary set of attributes
are from the symlink instance instead of from the real object was
too much difficult for me, so this year we've changed the dessign
of the application and don't need symlinks anymore.


jdavid

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments withORMapping

2001-05-14 Thread Karl Anderson

Casey Duncan [EMAIL PROTECTED] writes:

 I am not arguing necessarily for SQL as a query language for the ZODB.
 Although it is an accepted standard, but not a perfect one by any means
 especially for OODBs. Its appeal lies mainly in the high level of
 community familiarity and the plethora of SQL software to borrow from.

Does anyone have an opinion on the possible usefulness of XPath,
XQuery, and other XML standards for this?  Someone suggested (on the
zope-xml wiki) that it would be nice to be able to drop in a cataloger
that supported a presumably standard and presumably well-known XML
query syntax, and which would work throughout the database because
Zope objects would support DOM.

This is all speculation, and I personally don't know much right now
about XML database interfaces and how finished or well-regarded they
are.

-- 
Karl Anderson  [EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



RE: oodb philosophics ;) was: Re: [Zope-dev] Experiments withORMapping

2001-05-14 Thread Albert Langer

[Karl Anderson]
Casey Duncan [EMAIL PROTECTED] writes:

 I am not arguing necessarily for SQL as a query language for the ZODB.
 Although it is an accepted standard, but not a perfect one by any means
 especially for OODBs. Its appeal lies mainly in the high level of
 community familiarity and the plethora of SQL software to borrow from.

Does anyone have an opinion on the possible usefulness of XPath,
XQuery, and other XML standards for this?  Someone suggested (on the
zope-xml wiki) that it would be nice to be able to drop in a cataloger
that supported a presumably standard and presumably well-known XML
query syntax, and which would work throughout the database because
Zope objects would support DOM.

This is all speculation, and I personally don't know much right now
about XML database interfaces and how finished or well-regarded they
are.

[Albert]
An excellent introduction to this topic is:

Putting XML in context with hierarchical, relational, and
object-oriented models by David Mertz.
ftp://www6.software.ibm.com/software/developer/library/x-matters8.pdf

Author is a python developer with lots of interesting XML stuff.
See also his xml_matters 1 and 2 for xml_object and xml_pickle with
much nicer pythonic syntax instead of using DOM directly.

Article is also *essential* background for the distinction between
Object Mapping and Object Relational Mapping which needs to be
understood by anyone participating in this discussion.

An example of a python ODBMS with some partial support for OQL is 4ODS
from 4 Suite, which uses a very natural pythonic syntax for objects
stored in and queried from PostgreSQL:

Following is from 4Suite-docs-0.11/4Suite-0.11/html/4ODS-userguide.html
available via:

http://4suite.org/download.html#4Suite_Documentation


How to use the system (a very basic walk through)

First create a ODL file that represents what you want to store in test.odl

module simple {
  class person {
attribute string name;
attribute double weight;
relationship Person spouse inverse Person ::spouse_of;
relationship Person spouse_of inverse Person ::spouse;
relationship listPerson children  inverse Person ::child_of;
relationship Person child_of inverse Person ::children;
  };
  class employee (extends person) {
attribute string id;
  };
};

Now create a new database and initialize

 #OdlParse -ifp test test.odl

Now write some python code to do stuff with these people

#!/usr/bin/python

#Every thing that is persisten must be done inside a transaction and open
database
from Ft.Ods import Database
db = Database.Database()
db.open('test')

tx = db.new()
tx.begin()

#Create a new instance of some objects
import person
import employee
dad = employee.new()
mom = person.new()
son1 = person.new()
son2 = person.new()
daughter = person.new()

#Set some attributes
dad.name = Pops
mom.name = Ma
son1.name = Joey
son2.name = Bobby
daughter.name = Betty
dad.weight = 240.50

#We can set attributes not defined in the ODL but they will not persist
mom.address = 1234 Error Way


#Set some relationships

#First set a one to one relationship
dad.spouse = mom

#Or we could have done it via the ODMG spec
#dad.form_spouse(mom)

#Add some children to the dad (our data model does not let mom have
children.  We'd need a family struct (left up to the reader)

dad.add_children(son1)
#We can create relationships both ways
son2.form_child_of(dad)

#Shortcut for adding
dad.children = daughter

#Now root the family to some top level object.
db.bind(dad,The Fam)

#Make it so
tx.commit()

#Out side of a transaction we can still access the objects.
#However, any changes we make will not persist.
#NOTE, because 4ODS caches relationships, any relationships that were not
traversed during the
#transaction, cannot be traversed now because an object cannot be loaded
from the db outside
#of a transaction.
print dad.name

#Start a new tx to fetch

tx = db.new()
tx.begin()

newDad = db.lookup(The Fam)

print newDad.name
print newDad.children[0].name
print newDad.spouse

#Discard this transaction
tx.abort()

Ft/Ods/test_suite and Ft/Ods/demo are good places to look for more examples
^^

See also:
http://www.xml.com/pub/a/2000/10/11/rdf/

Some other relevant references are:

Extraction of DBMS catalogs to XML using python.
http://hyperschema.sourceforge.net./

PostgreSQL as XML repository
http://zvon.org/index.php?nav_id=61
http://hopla.sourceforge.net/doc/README

Note that none of this has much to do with the original topic of
Object-*Relational* Mapping.

*Essential* background for understanding what an object-relational
persistence layer looks like is:

http://www.ambysoft.com/persistenceLayer.html

It isn't very long and there *absolutely* isn't any point discussing
how to design such an OR persistence layer without first reading
and fully understanding it. (I say that after having carefully
studied all the messages in this discussion - though I also said
so before ;-)

The rest of that web site has 

Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-13 Thread Joachim Werner

 This is true in the ZODB, but can be complicated by acquisition. If an
 object can acquire itself, it can cause issues. Plus it becomes
 difficult to know whether objects are clones or just identical
 instances, although this can be mitigated by exposing their Python
 instance id.

Acquisition is very cool, but it sometimes really sucks ... AFAIK you can
easily switch it off in your own Python products. But I am still fighting
with only getting private variables (i.e. not acquired ones) in DTML ...


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-13 Thread Joachim Werner

 Probably I'm daft because it is Friday night, but AFAIK ZODB and most
OODB's
 store an object only once, keyed by its object id. The rest is just
references
 through that oid, so objects that belong to more than one container can be
 added to all these containers and n:m relations are implemented by having
a
 list of objects on both sides.

Yes, but these references (let's call them symlinks ...) are not in the
standard Zope. Of course it should be easy to do these things, but except
for this from Shane I haven't seen anything so far:
http://www.zope.org/Members/hathawsh/Symlink/index_html

P.S.: Shane, have you developed Symlinks any further? I think they could be
extremely useful. I tried out the initial release and liked it, except for
the fact that the symlinks looked EXACTLY like real ones, so they can be
very irritating ...

Joachim


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-11 Thread Cees de Groot

Shane Hathaway [EMAIL PROTECTED] said:
That's one reason ZODB is so nice.  You can write an application without
writing a formal schema.

One of the reasons I am seriously considering to migrate our production
database from PostgreSQL to ZODB. I am about to implement our product
database, and it is just too darn complex to bother maintaining SQL tables for
it...

Actually OracleStorage and bsddbstorage, recently released, are designed
to address concerns about performance and reliability, and they do an
excellent job at it.  And I consider ZODB as real an OODB as anything
else.  (In some ways it's the best out there IMHO.)

I heard that OracleStorage was quite a bit slower? And from what I've seen
from FileStorage, it's a basic transaction log - what can be more reliable
than that?

Are people using ZODB for non-Zope data? I'd be very interested to discuss
things like emulating extents, patterns for indexing, etcetera...



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-11 Thread Joachim Werner

 The other motivations for an RDBMS are (1) people have existing schemas
 and want Zope to access the same data as their existing apps, and they
 want it to be transparent, and (2) tables with millions of entries are
 easily stored in Zope but the perception is that the catalog isn't as
 fast as a database index.  No one has done any tests AFAIK.

Then we should do these tests. E.g. I'd like to see:

- 20 GB of Word and PDF documents stored in the ZODB and full-text +
metadata indexed in ZCatalog
- the complete [EMAIL PROTECTED] mailing list archive in the ZODB

If Zope can handle those without the help of external tools (RDBMS etc.),
I'll use it for all our Document Management ...

 That's one reason ZODB is so nice.  You can write an application without
 writing a formal schema.

Another thing (from the Slashdot article earlier this week): In Java,
changes to the object structure mean recompile. In Zope, you can just do
them. with working refresh support this will even work without having to
restart the Zope process ...

  What about using a real oodb for zope? Dont remember any particular
  product name, but I heard something.

 Actually OracleStorage and bsddbstorage, recently released, are designed
 to address concerns about performance and reliability, and they do an
 excellent job at it.  And I consider ZODB as real an OODB as anything
 else.  (In some ways it's the best out there IMHO.)

Agreed. ZODB has a much longer proven history of success than most other
OODBs.



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments withORMapping

2001-05-11 Thread Ken Manheimer

On friday, 11 May, Joachim Warner wrote:

  The other motivations for an RDBMS are (1) people have existing schemas
  and want Zope to access the same data as their existing apps, and they
  want it to be transparent, and (2) tables with millions of entries are
  easily stored in Zope but the perception is that the catalog isn't as
  fast as a database index.  No one has done any tests AFAIK.
 
 Then we should do these tests. E.g. I'd like to see:
 
 - 20 GB of Word and PDF documents stored in the ZODB and full-text +
 metadata indexed in ZCatalog
 - the complete [EMAIL PROTECTED] mailing list archive in the ZODB
 
 If Zope can handle those without the help of external tools (RDBMS etc.),
 I'll use it for all our Document Management ...

As a matter of fact, we did a quick CMF demo that has the content of the
zope list, zope-dev, and many of the other zope.org lists, and the
comp.lang.python list for the past few years.  The catalog searches are
very very fast, i can't recall if the demo was set up with some
interesting canned CMF topics, but the things works well.

The picture isn't altogether rosy - the process of loading the objects was
arduous.  On the other hand, the exercise (actually, a subsequent one with
simpler article objects) served as the basis for tuning the cataloging
process, and may have helped it get a lot better.

If i have time next week, i'll see if we have the corpus online somewhere.  
(The lists were complete up to a few months ago.)  Eventually we'd like to
be incrementally stuffing new messages into the database as they arrive.

The catalog has required some substantial work investment, but from my
viewpoint (particularly since i haven't had to work on it!-), it's well
worth it.

  Actually OracleStorage and bsddbstorage, recently released, are designed
  to address concerns about performance and reliability, and they do an
  excellent job at it.  And I consider ZODB as real an OODB as anything
  else.  (In some ways it's the best out there IMHO.)
 
 Agreed. ZODB has a much longer proven history of success than most other
 OODBs.

It is quite useful!

I have no experience programming with other object databases, and very
little with relational databases, so i have no basis for comparison.  
What i do know, as a python and zope programmer, is that ZODB is
spectacularly useful as a persistent store - as flexible *and* as powerful
as i could want.  The addition of ZEO manages to significantly increase
that usefulness!  The work we/pythonlabs (and andrew kuchling, etc) is
doing to enable use of it as an independent entity can only help improve
it's usefulness for everyone.

Ken Manheimer
[EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-11 Thread Casey Duncan

Cees de Groot wrote:
 
 Shane Hathaway [EMAIL PROTECTED] said:
 That's one reason ZODB is so nice.  You can write an application without
 writing a formal schema.
 
 One of the reasons I am seriously considering to migrate our production
 database from PostgreSQL to ZODB. I am about to implement our product
 database, and it is just too darn complex to bother maintaining SQL tables for
 it...
 
 Actually OracleStorage and bsddbstorage, recently released, are designed
 to address concerns about performance and reliability, and they do an
 excellent job at it.  And I consider ZODB as real an OODB as anything
 else.  (In some ways it's the best out there IMHO.)
 
 I heard that OracleStorage was quite a bit slower? And from what I've seen
 from FileStorage, it's a basic transaction log - what can be more reliable
 than that?
 
 Are people using ZODB for non-Zope data? I'd be very interested to discuss
 things like emulating extents, patterns for indexing, etcetera...
 

One of the biggest limitations in my mind is the lack of a general query
language for the ZODB like what you get with most OODBMS and all RDBMS.
ZCatalog is improving, but it is just not quite there yet.

I do feel that the ZODB is quite robust, and with the added option of
berkeley storage along with others, you have several back-end choices.

-- 
| Casey Duncan
| Kaivo, Inc.
| [EMAIL PROTECTED]
`--

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-11 Thread David Brown

At 11:45 AM 5/11/2001 -0600, Casey Duncan wrote:

One of the biggest limitations in my mind is the lack of a general query
language for the ZODB like what you get with most OODBMS and all RDBMS.

I used to think this as well.

But isn't Python a decent query language?  Isn't it nice to be able to have 
all of the facilities of Python at your disposal when manipulating data, 
rather than hoping that whatever database you are using doesn't have a 
brain-damaged implementation of SQL?

Isn't it nice not to have to convert back and forth between SQL types and 
native types?  Isn't it nice not to have to swap in your SQL mind in the 
middle of your Python program?

Having a general query language makes it easy for people who know that 
particular general query language to write programs.  It makes it easy to 
access a bunch of different data sources, at least until the monster named 
implementation differences rears it's ugly head.

We've all spent years learning to make our programs interface with 
databases, learning how to jump the mental chasm between our programs and 
they way they want to manipulate data, and the way that the database wants 
to manipulate data.  Isn't it nice not to have to do that any more?

Don't get me wrong, I believe I get your point.  SQL implementations are 
getting more and more compatible.  There are OODBMS query languages 
specified.  There's no really good way of making different programming 
languages and programming environments interoperate without some sort of 
common meeting ground, like a general query language.

And perhaps I'm overdoing the response, perhaps I've gone off in a 
different direction.  I've just been thinking about this quite a bit lately.

dave


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments withORMapping

2001-05-11 Thread Joachim Werner

 As a matter of fact, we did a quick CMF demo that has the content of the
 zope list, zope-dev, and many of the other zope.org lists, and the
 comp.lang.python list for the past few years.  The catalog searches are
 very very fast, i can't recall if the demo was set up with some
 interesting canned CMF topics, but the things works well.

Sounds very promising ...

 The picture isn't altogether rosy - the process of loading the objects was
 arduous.

What exactly were the problems? I mean, uploading and indexing thousands of
documents IS a big deal. I'm sure that any other indexing system will take a
lot of time for this, too.

Joachim


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-11 Thread Joachim Werner

 But isn't Python a decent query language?  Isn't it nice to be able to
have
 all of the facilities of Python at your disposal when manipulating data,
 rather than hoping that whatever database you are using doesn't have a
 brain-damaged implementation of SQL?

Most of the time nobody will need SQL. And having a transparent,
transaction-aware and undoable persistent Object store is really a cool
thing. But from time to time you will hit walls. That's when the object
paradigm just does not do the job completely well any more. E.g. how would
you handle objects beloning to more than one container? In SQL this is easy
(Just have a table that matches key pairs from the container table and the
item table). And I don't know any good way of implementing many-to-many
relations in object hierarchies. Let alone querying them efficiently.

Joachim


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments withORMapping

2001-05-11 Thread Casey Duncan

David Brown wrote:
 
 At 11:45 AM 5/11/2001 -0600, Casey Duncan wrote:
 
 One of the biggest limitations in my mind is the lack of a general query
 language for the ZODB like what you get with most OODBMS and all RDBMS.
 
 I used to think this as well.
 
 But isn't Python a decent query language?  Isn't it nice to be able to have
 all of the facilities of Python at your disposal when manipulating data,
 rather than hoping that whatever database you are using doesn't have a
 brain-damaged implementation of SQL?

No and yes. Python is a great oop language, it has no inherent querying
capabilites though outside of namespace lookups (with acquisition when
in Zope) and dictionaries. You would need to build in all possible
queries as Python methods none of which would be very general. This is
something you need not do with a general query language where you can
make arbitrary queries at will.

 Isn't it nice not to have to convert back and forth between SQL types and
 native types?  Isn't it nice not to have to swap in your SQL mind in the
 middle of your Python program?

I am not arguing necessarily for SQL as a query language for the ZODB.
Although it is an accepted standard, but not a perfect one by any means
especially for OODBs. Its appeal lies mainly in the high level of
community familiarity and the plethora of SQL software to borrow from.
 
 Having a general query language makes it easy for people who know that
 particular general query language to write programs.  It makes it easy to
 access a bunch of different data sources, at least until the monster named
 implementation differences rears it's ugly head.
 
 We've all spent years learning to make our programs interface with
 databases, learning how to jump the mental chasm between our programs and
 they way they want to manipulate data, and the way that the database wants
 to manipulate data.  Isn't it nice not to have to do that any more?

Yes, I would argue for a tight integration between the query mechanism
and regular Python, something that Catalogs have begun to implement.
However their query language is a very limiting argument list. Perhaps a
more general Python based query language of some kind needs to be
developed. Something like an expression that returns the set of objects
that meet its criteria. Exactly what this would be would need much
community (Python and Zope) discussion. A start to this discussion can
be found here:

http://dev.zope.org/Wikis/DevSite/Proposals/UnionAndIntersectionOperations

 
 Don't get me wrong, I believe I get your point.  SQL implementations are
 getting more and more compatible.  There are OODBMS query languages
 specified.  There's no really good way of making different programming
 languages and programming environments interoperate without some sort of
 common meeting ground, like a general query language.

A be all query language for all databases (Which would be SQL at this
point, which is not necessarily tailored to OODBs) will always have
compromises and flaws. I look at something like CORBA which is can be
used to tie programs of all different languages together. Unfortunately
the result of reconsiling COBOL, C, Python, Java, Perl, BASIC, etc. to
some common ground is not always very pretty.

I would really be happy just to get Python (and possibly C) to be able
to perform general ZODB queries without resorting to kludges like
spam_usage='range:min:max'. So what I am talking about is not really
general, but mostly Python/ZODB specific.

 
 And perhaps I'm overdoing the response, perhaps I've gone off in a
 different direction.  I've just been thinking about this quite a bit lately.
 
 dave

I think this is a very important topic of discussion. Thanks for adding
your thoughts!

-- 
| Casey Duncan
| Kaivo, Inc.
| [EMAIL PROTECTED]
`--

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-11 Thread David Brown

At 08:38 PM 5/11/2001 +0200, you wrote:

 E.g. how would
 you handle objects beloning to more than one container? In SQL this is easy
 (Just have a table that matches key pairs from the container table and the
 item table).

I could do the same thing with Python, creating a dictionary that does the 
mapping.  You'd have to maintain the dictionary, sure, but you'd have to 
maintain the table in a relational database as well.

  And I don't know any good way of implementing many-to-many
 relations in object hierarchies. Let alone querying them efficiently.

Well, then we need a many-to-many mapping object.  The point is that we 
could do this in Python and make the classes available, rather than 
morphing our thought processes into whatever shape the RDBMS wants.

We're just missing some functionality, but it can be written without 
rewriting the database code, because we can just store our objects 
(representing indices or mappings or whatever) directly.

The cool thing about object stores is that you can use the object modeling 
tools to do the job, and come up with specific (and more efficient) 
solutions, rather than mapping a general (and possibly slower) solution 
onto a specific problem.

dave


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with

2001-05-11 Thread Casey Duncan

Cees de Groot wrote:
 
 David Brown [EMAIL PROTECTED] said:
 But isn't Python a decent query language?  Isn't it nice to be able to have
 all of the facilities of Python at your disposal when manipulating data,
 rather than hoping that whatever database you are using doesn't have a
 brain-damaged implementation of SQL?
 
 Yup. Our business objects are sitting on top of my homebrew O/R mapping layer,
 and I find myself entering the Python shell to do ad-hoc stuff with them more
 and more often. Especially because stuff that repeats one or two times is
 easily added as a method on the object for later reference...
 
 One nice idea that should be possible in Pythonland as well: a Smalltalk O/R
 mapping layer called GLORP uses Smalltalk as a query language in a very nice
 way. Queries are given as Smalltalk blocks (say lambdas), and the mapping
 layer interprets the block's parse tree in order to spit out equivalent SQL
 code. Say:
 
 Employees.get(lambda e: e.name[:3] == 'Foo')
 
 to get all employees that have a name starting with Foo.
 

The only problem with this is that lambdas are not safe for TTW
scripting 8^(.

Although a safe lambda could probably be conceived of course...

-- 
| Casey Duncan
| Kaivo, Inc.
| [EMAIL PROTECTED]
`--

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with

2001-05-11 Thread Cees de Groot


[EMAIL PROTECTED] said:
 The only problem with this is that lambdas are not safe for TTW
 scripting 8^(.

I think that TTW scripting and heavy duty application development are very 
incompatible with each other, so that's not a problem :-)


-- 
Cees de Groot   http://www.cdegroot.com [EMAIL PROTECTED]
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-11 Thread Cees de Groot

Joachim Werner [EMAIL PROTECTED] said:
[...]. E.g. how would
you handle objects beloning to more than one container? In SQL this is easy
(Just have a table that matches key pairs from the container table and the
item table). And I don't know any good way of implementing many-to-many
relations in object hierarchies. Let alone querying them efficiently.

Probably I'm daft because it is Friday night, but AFAIK ZODB and most OODB's
store an object only once, keyed by its object id. The rest is just references
through that oid, so objects that belong to more than one container can be
added to all these containers and n:m relations are implemented by having a
list of objects on both sides. 


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-10 Thread Shane Hathaway

Tino Wildenhain wrote:
 I think the motivation people want an RDBMS storage beneth zodb is
 because they understand RDBMSes these days are performant, relieable
 and can quiete easy maintained.

The other motivations for an RDBMS are (1) people have existing schemas
and want Zope to access the same data as their existing apps, and they
want it to be transparent, and (2) tables with millions of entries are
easily stored in Zope but the perception is that the catalog isn't as
fast as a database index.  No one has done any tests AFAIK.

 I've seen Java implementations using this approach to achive persistens
 using as example Powertier[tm] to explicit map oop data to an RDBMS.
 I didnt like it because you have to map your objects each time you create
 a class, keep in mind not to infere with others etc...

That's one reason ZODB is so nice.  You can write an application without
writing a formal schema.

 Would it not be better to improve the abilities of the Filestorage
 to handle updates better? May be most of the storage system in C?
 With logfiles like modern RDBMSes use to incorporate fast changes?
 However, to avoid pickling/unpickling and may be to update on
 attribute-change, we need the approach you mentioned.
 
 What about using a real oodb for zope? Dont remember any particular
 product name, but I heard something.

Actually OracleStorage and bsddbstorage, recently released, are designed
to address concerns about performance and reliability, and they do an
excellent job at it.  And I consider ZODB as real an OODB as anything
else.  (In some ways it's the best out there IMHO.)

Shane

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments with ORMapping

2001-05-10 Thread Casey Duncan

Tino Wildenhain wrote:
 
 Hi shane,
 
 I think the motivation people want an RDBMS storage beneth zodb is
 because they understand RDBMSes these days are performant, relieable
 and can quiete easy maintained.
 
 I've seen Java implementations using this approach to achive persistens
 using as example Powertier[tm] to explicit map oop data to an RDBMS.
 I didnt like it because you have to map your objects each time you create
 a class, keep in mind not to infere with others etc...
 
 Would it not be better to improve the abilities of the Filestorage
 to handle updates better? May be most of the storage system in C?
 With logfiles like modern RDBMSes use to incorporate fast changes?
 However, to avoid pickling/unpickling and may be to update on
 attribute-change, we need the approach you mentioned.
 
 What about using a real oodb for zope? Dont remember any particular
 product name, but I heard something.
 
 Regards
 Tino Wildenhain
 

It would certainly be an interseting exercise to put Matisse or
Objectivity behind Zope as ZODB storage, however I think there will
always be kludgeyness because features of Zope wont directly map (like
versions).

I think the Berkeley storage option will eventually prove to be the
ticket. Probably sooner than later.

How about XML storage! 8^) You think startup times are slow now...

-- 
| Casey Duncan
| Kaivo, Inc.
| [EMAIL PROTECTED]
`--

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )