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.
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
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
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
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
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
16 matches
Mail list logo
