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
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
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
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.
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
[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
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
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
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
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
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
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
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
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
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
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?
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
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
[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
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
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
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
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
23 matches
Mail list logo
