Aaron Stone wrote:
> On Tue, 2007-06-05 at 23:03 +1000, Jake Anderson wrote:
>
>>> Now that I've written all that, I am sure that should happen in the
>>> database, in the replication code. It's just not likely to happen any
>>> time soon :-\
>>>
>>> Aaron
>>>
>>>
>> You mean that it s
On Tue, 2007-06-05 at 23:03 +1000, Jake Anderson wrote:
> > Now that I've written all that, I am sure that should happen in the
> > database, in the replication code. It's just not likely to happen any
> > time soon :-\
> >
> > Aaron
> >
> You mean that it should be taken care of by stored proce
On Tue, Jun 5, 2007, Marc Dirix <[EMAIL PROTECTED]> said:
>>
>> If we take control of replication, it means that we have to add a
>> lot of
>> meta-information to the database about where the data is being stored
>> and knowing how to re-duplicate that information when one of its
>> stores
>>
If we take control of replication, it means that we have to add a
lot of
meta-information to the database about where the data is being stored
and knowing how to re-duplicate that information when one of its
stores
goes down (for example, ensure that each message is duplicated on at
least 3
> Now that I've written all that, I am sure that should happen in the
> database, in the replication code. It's just not likely to happen any
> time soon :-\
>
> Aaron
>
You mean that it should be taken care of by stored procedures and the
like? That sounds really quite hard ;->
I'd do it this
On Tue, 2007-06-05 at 00:21 +1000, Jake Anderson wrote:
> Aaron Stone wrote:
> > This is looking really good!
> >
> > Rather than pushing the next_uid generator down into the database,
> > however, I'd like to see it happen in a function up at the application
> > level. This way we can easily hook
Aaron Stone wrote:
> This is looking really good!
>
> Rather than pushing the next_uid generator down into the database,
> however, I'd like to see it happen in a function up at the application
> level. This way we can easily hook up some cluster coordination code.
> For your first pass, the functi
This is looking really good!
Rather than pushing the next_uid generator down into the database,
however, I'd like to see it happen in a function up at the application
level. This way we can easily hook up some cluster coordination code.
For your first pass, the function would just do the same thin
Looks very interesting James. Keep us posted. Getting rid of the global
message uid sequence gets my vote.
James Cloos wrote:
> This is where I am at in converting to per-mailbox uid values for imap.
>
> I still need to port the trigger to sqlite and write some equivilent
> code for mysql (I p
This is where I am at in converting to per-mailbox uid values for imap.
I still need to port the trigger to sqlite and write some equivilent
code for mysql (I presume compatability with versions of mysql which
do not support stored procedures is required?), write a transition
schema for each, and
10 matches
Mail list logo
