>
> > 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 s
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 mitigate
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 con
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 mitigate
> 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 impleme
> 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.
Acquisiti
[EMAIL PROTECTED] said:
> This is true in the ZODB, but can be complicated by acquisition.
Cheap cop-out: I was planning to avoid acquisition in my "business object"
database (which will be a database separate from the Zope ZODB). Personally,
I'm not very convinced of the necessity and advanta
Cees de Groot wrote:
>
> 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
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"
>relat
[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.c
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
> >br
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 doe
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 S
> 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 nee
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 t
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
> 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
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
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
> usin
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
20 matches
Mail list logo
