Alex wrote:
Yes, what about firing the DELETE trigger? During REPLACE a row is deleted,
isn't it?
That's the way REPLACE works, yes. So one could reasonably argue for
a DELETE trigger to fire on a REPLACE.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
> >I do not consider this a bug. INSERT OR REPLACE is not an UPDATE so
> >an UPDATE trigger should not fire on an INSERT OR REPLACE. So don't
> >be looking for me to change it anytime soon.
> >
>
> I was thinking more along the lines of a DELETE. That would be an accurate
> semantic, would it not
Christian Smith wrote:
I was thinking more along the lines of a DELETE. That would be an accurate
semantic, would it not?
Yes.
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
On Tue, 12 Oct 2004, D. Richard Hipp wrote:
>Christian Smith wrote:
>>
>> If this issue is critical to your project, you should perhaps contract
>> Richard to do the changes, as I can't give any guarantees on ever getting
>> round to implementing this. I'm still in the code familiarisation phase.
Christian Smith wrote:
If this issue is critical to your project, you should perhaps contract
Richard to do the changes, as I can't give any guarantees on ever getting
round to implementing this. I'm still in the code familiarisation phase.
I do not consider this a bug. INSERT OR REPLACE is not an
On Tue, 12 Oct 2004, Alex wrote:
>Hi
>
>> Existing ticket #368 may cover this behaviour. I guess Ron is the user who
>> added the latest remark:
>> http://www.sqlite.org/cvstrac/tktview?tn=368
>>
>> If I have time at the weekend, I might have a bash at producing a patch
>> that will implement what
Hi
> Existing ticket #368 may cover this behaviour. I guess Ron is the user who
> added the latest remark:
> http://www.sqlite.org/cvstrac/tktview?tn=368
>
> If I have time at the weekend, I might have a bash at producing a patch
> that will implement what is required. No promises, mind.
>
> What
> I'd probably initially do it for 3.x, as 2.x is basically in feature
> freeze, I believe. Are you 2.x based?
Yes, I am, for it was the only stable version when the project was started.
And I'd prefer to stay on it since version 3 is too young, its docs are not
complete (AFAIK). So, if possible,
On Thu, 23 Sep 2004, Alex wrote:
>> If I have time at the weekend, I might have a bash at producing a patch
>> that will implement what is required. No promises, mind.
>>
>> What would be preferred? Convert the trigger to an update trigger, or fire
>> a delete trigger followed by an insert trigger
> If I have time at the weekend, I might have a bash at producing a patch
> that will implement what is required. No promises, mind.
>
> What would be preferred? Convert the trigger to an update trigger, or fire
> a delete trigger followed by an insert trigger?
>
> I'd prefer the former (update) as
On Tue, 21 Sep 2004, Alex wrote:
>> But I think the gist of you email is that you'd prefer the "INSERT OR
>> REPLACE" to be handled like an update. I can't see a reason why an OLD
>> record could be created for replace inserts. The problem then becomes how
>> do you know in the trigger whether OLD
> But I think the gist of you email is that you'd prefer the "INSERT OR
> REPLACE" to be handled like an update. I can't see a reason why an OLD
> record could be created for replace inserts. The problem then becomes how
> do you know in the trigger whether OLD is valid? If the insert is a
> straig
> CREATE TABLE table (ID text UNIQUE, Name text, Surname text, SecDbKey text)
> INSERT INTO table VALUES ('001', 'John', 'Smith', 'A0B1C2D3')
> INSERT OR REPLACE INTO table VALUES ('001', 'Jane', 'Parker', 'E4F51234')
I'm not sure exactly what relationship you're trying to maintain
between this ta
On Tue, September 21, 2004 11:26, Christian Smith said:
> On Tue, 21 Sep 2004, Alex wrote:
>
> In which case it might be better to convert the replace insert into an
> update, and use the update trigger which is guaranteed to have valid OLD
> and NEW.
>
> But that is not my decision to make. Crea
On Tue, 21 Sep 2004, Alex wrote:
>Hi, Christian
>
>Thanks for your response. The situation, however, is more complicated.
>Please, consider an example in SQL:
>
>CREATE TABLE table (ID text UNIQUE, Name text, Surname text, SecDbKey text)
>
>INSERT INTO table VALUES ('001', 'John', 'Smith', 'A0B1C2
Alex wrote:
> Hi, Christian
>
> Thanks for your response. The situation, however, is more complicated.
> Please, consider an example in SQL:
>
> CREATE TABLE table (ID text UNIQUE, Name text, Surname text, SecDbKey
> text)
>
> INSERT INTO table VALUES ('001', 'John', 'Smith', 'A0B1C2D3')
>
> INSERT
"Alex" <[EMAIL PROTECTED]> writes:
> CREATE TABLE table (ID text UNIQUE, Name text, Surname text, SecDbKey text)
>
> INSERT INTO table VALUES ('001', 'John', 'Smith', 'A0B1C2D3')
>
> INSERT OR REPLACE INTO table VALUES ('001', 'Jane', 'Parker', 'E4F51234')
>
> In the given example the "UNIQUE" con
Hi, Christian
Thanks for your response. The situation, however, is more complicated.
Please, consider an example in SQL:
CREATE TABLE table (ID text UNIQUE, Name text, Surname text, SecDbKey text)
INSERT INTO table VALUES ('001', 'John', 'Smith', 'A0B1C2D3')
INSERT OR REPLACE INTO table VALUES
On Sun, 19 Sep 2004, Alex wrote:
>Hi,
>
>The point is that if the OR REPLACE clause is specified, INSERT may
>overwrite an existing row instead of inserting a new one. In this case the
>appropriate record in the secondary db must be deleted. However, I cannot do
>it because OLD is not available in
Hi,
In my project I have two databases: primary which is an SQLite db, and
secondary which is based on a different engine. A table in the primary db
contains values which are keys for the secondary db. To maintain coherence
of the two databases I use SQLite triggers. The DELETE and UPDATE commands
20 matches
Mail list logo
