--On 25. Juni 2006 21:33:21 +0200 Dieter Maurer <[EMAIL PROTECTED]> wrote:
Andreas Jung wrote at 2006-6-24 22:36 +0200:
...
The ZODB model (object data stored in a storage with behaviour
coded in the clients) is powerful enough to simply
implement the relational database data struct
Andreas Jung wrote at 2006-6-24 22:36 +0200:
> ...
>>The ZODB model (object data stored in a storage with behaviour
>>coded in the clients) is powerful enough to simply
>>implement the relational database data structures: tables
>>and indexes and their corresponding operations.
>>
>
Roché Compaan wrote at 2006-6-25 11:13 +0200:
> ...
>> Careful design with respect to the granularity and locality
>> of persistent objects:
>>
>> Move groups of large and rarely used attributes out
>> into persistent subobjects.
>
>Will this lead to smaller transaction sizes for objects that
On Sat, 2006-06-24 at 20:54 +0200, Dieter Maurer wrote:
> Roché Compaan wrote at 2006-6-24 08:53 +0200:
> > ...
> >I am curious what other strategies besides QueueCatalog you employ?
>
> Careful design with respect to the granularity and locality
> of persistent objects:
>
> Move groups of larg
--On 24. Juni 2006 21:08:03 +0200 Dieter Maurer <[EMAIL PROTECTED]> wrote:
Andreas Jung wrote at 2006-6-24 09:24 +0200:
...
One particular app that I have been working on uses very complex queries
with lots of join etcit would be hard model to implement such
queries on top of the ZODB/ZC
Andreas Jung wrote at 2006-6-24 09:24 +0200:
> ...
>One particular app that I have been working on uses very complex queries
>with lots of join etcit would be hard model to implement such queries
>on top of the ZODB/ZCatalog.
I disagree with you (partially).
The ZODB model (object data s
Roché Compaan wrote at 2006-6-24 08:53 +0200:
> ...
>I am curious what other strategies besides QueueCatalog you employ?
Careful design with respect to the granularity and locality
of persistent objects:
Move groups of large and rarely used attributes out
into persistent subobjects.
Move g
On Sat, 2006-06-24 at 09:24 +0200, Andreas Jung wrote:
>
> --On 24. Juni 2006 08:53:43 +0200 Roché Compaan
> <[EMAIL PROTECTED]> wrote:
>
> > I am curious what other strategies besides QueueCatalog you employ? Do
> > you ever use multiple backends for your apps? How do you decide that
> > this d
--On 24. Juni 2006 08:53:43 +0200 Roché Compaan
<[EMAIL PROTECTED]> wrote:
I am curious what other strategies besides QueueCatalog you employ? Do
you ever use multiple backends for your apps? How do you decide that
this data belongs in a relational backend? How structured must the data
be, o
On Fri, 2006-06-23 at 22:03 +0200, Dieter Maurer wrote:
> Adam Groszer wrote at 2006-6-23 14:27 +0200:
> > ...
> >Some fears they are having and I can't find unambiguous information:
> >- Is ZODB a good choice for this app?
>
> It depends...
> At least careful design is necessary!
>
> The most pr
Adam Groszer wrote at 2006-6-23 14:27 +0200:
> ...
>Some fears they are having and I can't find unambiguous information:
>- Is ZODB a good choice for this app?
It depends...
At least careful design is necessary!
The most problematic aspects of the ZODB are write conflicts.
When two concurrent
--On 23. Juni 2006 14:27:52 +0200 Adam Groszer <[EMAIL PROTECTED]> wrote:
Hi there,
I know it is not easy, but I need some advices to keep our bosses
happy at the planning stage of our application.
The application we are planning is a document management application
which follows documents i
12 matches
Mail list logo
