On Thu, Nov 20, 2003 at 10:03:51AM -0800, Eric Soroos wrote:
> >Well, as you have stated there is a non zero possibility to get the
> >same fingerprint for two different messageblocks.
>
> Non-zero, but on the order of 1 in 2^127 chance, or virtually never in
> the age of the universe, at least
Well the first is something I have found out earlier, consider a table
with the fields A and B and the following records:
A B
1 1
1 2
2 1
for that record, you can not add the constraint UNIQUE(A) nor
UNIQUE(B), but you can add the constraint UNIQUE(A,B)
Correct. But if we're starting with A
Eric Soroos wrote:
On Nov 20, 2003, at 8:28 AM, Magnus Sundberg wrote:
Eric Soroos wrote:
You can. That's effectively what I was doing in my message, except
that you're not seeing it in the messageblk view. You probably
don't want a unique constraint on messageblk, since the idea of the
On Nov 20, 2003, at 8:28 AM, Magnus Sundberg wrote:
Eric Soroos wrote:
You can. That's effectively what I was doing in my message, except
that you're not seeing it in the messageblk view. You probably
don't want a unique constraint on messageblk, since the idea of the
fingerprint is that it
Eric Soroos wrote:
You can. That's effectively what I was doing in my message, except
that you're not seeing it in the messageblk view. You probably don't
want a unique constraint on messageblk, since the idea of the
fingerprint is that it's a 1:1 mapping of the messageblk down to 128
bits.
You can. That's effectively what I was doing in my message, except
that you're not seeing it in the messageblk view. You probably don't
want a unique constraint on messageblk, since the idea of the
fingerprint is that it's a 1:1 mapping of the messageblk down to 128
bits.
I agree with you i
Eric Soroos wrote:
Why can't you store the msg_block fingerprint in the msg_block table?
Like (with mysql syntax)
CREATE TABLE messageblks (
messageblk_idnr bigint(21) NOT NULL auto_increment,
physmessage_id bigint(21) NOT NULL default '0',
messageblk longtext NOT NULL,
blocks
Why can't you store the msg_block fingerprint in the msg_block table?
Like (with mysql syntax)
CREATE TABLE messageblks (
messageblk_idnr bigint(21) NOT NULL auto_increment,
physmessage_id bigint(21) NOT NULL default '0',
messageblk longtext NOT NULL,
blocksize b
quick question. Why remove physmessage? Can't you use it to your
advantage here? The physmessage table already makes sure that multiple
copies of a single message will only be stored as messageblocks once.
You should be able to use this to allow multiple users to use the same
physmessage. Or i
Eric Soroos wrote:
I believe your choice is better, in that, it requires many less
changes to
the underlying db_ methods, so I'll back mine out and proceed with
yours. I
may need one new db_ method to add a user mailbox to an existing message.
I think there's a way to do this entirely i
On Nov 18, 2003, at 10:46 AM, Gary Murphy wrote:
The current quota implementation is definitely costly. Establishing a
transaction with failure and/or over-quota control for the message
inserts
(rollback inserted data) could be a first step; but I agree a more
elegant
solution is desirable.
I believe your choice is better, in that, it requires many less
changes to
the underlying db_ methods, so I'll back mine out and proceed with
yours. I
may need one new db_ method to add a user mailbox to an existing
message.
I think there's a way to do this entirely in the the database laye
Ilja:
> On Wednesday, November 19, 2003 2:32 AM Ilja Booij wrote:
> Hi,
>
> On Nov 18, 2003, at 7:46 PM, Gary Murphy wrote:
>>
>>
>> For a more radical storage saving approach we could consider storing
>> only
>> one copy of a message for all recipients within the database
> Quick question. Wh
Hi,
On Nov 18, 2003, at 7:46 PM, Gary Murphy wrote:
For a more radical storage saving approach we could consider storing
only
one copy of a message for all recipients within the database. This is
the
approach Oracle uses for its email package. My users are insisting on
this
so, I am alre
On Tue, Nov 18, 2003 at 01:34:58PM -0600, Gary Murphy wrote:
> The new table contains message_idnr, mailbox_idnr + all message flags. The
> messages table no longer contains copies of these. This allows one user to
> store multiple copies of a message as long as she/he only stores one copy in
> a
Christian:
On Tuesday, November 18, 2003 1:07 PM Christian G. Warden wrote:
> On Tue, Nov 18, 2003 at 12:46:30PM -0600, Gary Murphy wrote:
>>
>> For a more radical storage saving approach we could consider storing only
>> one copy of a message for all recipients within the database. This is
the
On Tue, Nov 18, 2003 at 12:46:30PM -0600, Gary Murphy wrote:
>
> For a more radical storage saving approach we could consider storing only
> one copy of a message for all recipients within the database. This is the
> approach Oracle uses for its email package. My users are insisting on this
> so
Eric:
On Tuesday, November 18, 2003 12:18 AM, Eric Soroos wrote:
> On Nov 17, 2003, at 7:20 AM, Gary Murphy wrote:
> Correct, although you don't actually need to rollback a transaction
> postgres if there's a error reported from the database, as it puts the
> entire transaction into an abort st
On Nov 17, 2003, at 7:20 AM, Gary Murphy wrote:
Ilja:
To truly benefit from transaction control you really need to
advantage, not
just by grouping DML statements, but also by use of the "rollback"
statement
in the case of an individual statement's failure.
Correct, although you don't actual
age-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
> Of Gary Murphy
> Sent: Monday, November 17, 2003 9:21 AM
> To: dbmail@dbmail.org
> Subject: RE: [Dbmail] 2.0 and transactions
> Ilja:
> To truly benefit from transaction control you really need to advantage,
no
ooij
Sent: Monday, November 17, 2003 4:42 AM
To: dbmail@dbmail.org
Subject: Re: [Dbmail] 2.0 and transactions
Hi,
On Nov 14, 2003, at 11:16 PM, Eric Soroos wrote:
>
> Now that I have 2.0 built, I was poking around a bit and noticed that
> there are no transactions used. This will tend
Hi,
On Nov 14, 2003, at 11:16 PM, Eric Soroos wrote:
Now that I have 2.0 built, I was poking around a bit and noticed that
there are no transactions used. This will tend to hurt performance (at
least for postgresql) for inserts and that sort of thing since the
database can batch writes to th
Now that I have 2.0 built, I was poking around a bit and noticed that
there are no transactions used. This will tend to hurt performance (at
least for postgresql) for inserts and that sort of thing since the
database can batch writes to the database during a transaction.
With a really basic ad
23 matches
Mail list logo
