PHWinfo banniere

Titres
PORTAIL ANNUAIRE ARTICLES COMPARATEUR HÉBERGEURS DEVIS FORUMS RÉDUCTEUR D'URL
Précédent   PHWinfo > Autres forums > Forum Programmation & Conception > comp.databases.mysql > bug with insert select?
S'inscrire FAQ Membres Recherche Messages du jour Marquer les forums comme lus
bug with insert select?

Réponse
 
LinkBack Outils de la discussion
Vieux 18/10/2007, 11h28   #1
fmardini
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut bug with insert select?

I think I might have found a bug with insert select when inserting
into the same table and using a composite primary key
I made the smallest example I could come up with

CREATE TABLE `t1` (
`id1` int(11) NOT NULL,
`id2` int(11) NOT NULL,
`val1` int(11) default '0',
`val2` int(11) default '0',
PRIMARY KEY (`id1`,`id2`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

CREATE VIEW t1v AS SELECT * FROM t1

INSERT INTO t1 (`id1`, `id2`, `val1`, `val2`) VALUES (1, 1, 1, 10),
(1, 2, 2, 20), (1, 3, 3, 30), (2, 1, 1, 40), (2, 2, 2, 50), (2, 3, 3,
60)

I want to insert into the table from itself
I use the view as a way to reference the selected row as opposed to
the found (duplicate) row (otherwise i get an ambiguous reference
error)

INSERT INTO t1
SELECT 1, id2, 0, 100
FROM t1v WHERE id1 = 2
ON DUPLICATE KEY UPDATE t1.val2 = t1v.val1 + 100

After executing the query, the contents of the table are

1 1 1 103
1 2 2 103
1 3 3 103
2 1 1 40
2 2 2 50
2 3 3 60

I was expecting the following

1 1 1 101
1 2 2 102
1 3 3 103
2 1 1 40
2 2 2 50
2 3 3 60

Am I doing something wrong or is this a bug with INSERT SELECT
If this is the wrong list, please tell me where to post

thanks
fmardini

  Réponse avec citation
Vieux 18/10/2007, 11h54   #2
Captain Paralytic
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: bug with insert select?

On 18 Oct, 10:28, fmardini <f.mard...@gmail.com> wrote:
> I think I might have found a bug with insert select when inserting
> into the same table and using a composite primary key
> I made the smallest example I could come up with
>
> CREATE TABLE `t1` (
> `id1` int(11) NOT NULL,
> `id2` int(11) NOT NULL,
> `val1` int(11) default '0',
> `val2` int(11) default '0',
> PRIMARY KEY (`id1`,`id2`)
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8
>
> CREATE VIEW t1v AS SELECT * FROM t1
>
> INSERT INTO t1 (`id1`, `id2`, `val1`, `val2`) VALUES (1, 1, 1, 10),
> (1, 2, 2, 20), (1, 3, 3, 30), (2, 1, 1, 40), (2, 2, 2, 50), (2, 3, 3,
> 60)
>
> I want to insert into the table from itself
> I use the view as a way to reference the selected row as opposed to
> the found (duplicate) row (otherwise i get an ambiguous reference
> error)

You wouldn't get the ambiguous reference error if you simply gave your
table references unque aliases.

> INSERT INTO t1
> SELECT 1, id2, 0, 100
> FROM t1v WHERE id1 = 2
> ON DUPLICATE KEY UPDATE t1.val2 = t1v.val1 + 100

You are not using the complete composite primary key, so the last row
encountered with the partial key in the WHERE clause will update the
rows. This is not a bug, it is what you told it to do.

You have posted sample data inserts and create statements so I will
load it into a table so I can see what you want the transformation to
look like.

  Réponse avec citation
Vieux 18/10/2007, 12h21   #3
Captain Paralytic
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: bug with insert select?

On 18 Oct, 10:28, fmardini <f.mard...@gmail.com> wrote:
> I think I might have found a bug with insert select when inserting
> into the same table and using a composite primary key
> I made the smallest example I could come up with
>
> CREATE TABLE `t1` (
> `id1` int(11) NOT NULL,
> `id2` int(11) NOT NULL,
> `val1` int(11) default '0',
> `val2` int(11) default '0',
> PRIMARY KEY (`id1`,`id2`)
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8
>
> CREATE VIEW t1v AS SELECT * FROM t1
>
> INSERT INTO t1 (`id1`, `id2`, `val1`, `val2`) VALUES (1, 1, 1, 10),
> (1, 2, 2, 20), (1, 3, 3, 30), (2, 1, 1, 40), (2, 2, 2, 50), (2, 3, 3,
> 60)
>
> I want to insert into the table from itself
> I use the view as a way to reference the selected row as opposed to
> the found (duplicate) row (otherwise i get an ambiguous reference
> error)
>
> INSERT INTO t1
> SELECT 1, id2, 0, 100
> FROM t1v WHERE id1 = 2
> ON DUPLICATE KEY UPDATE t1.val2 = t1v.val1 + 100
>
> After executing the query, the contents of the table are
>
> 1 1 1 103
> 1 2 2 103
> 1 3 3 103
> 2 1 1 40
> 2 2 2 50
> 2 3 3 60
>
> I was expecting the following
>
> 1 1 1 101
> 1 2 2 102
> 1 3 3 103
> 2 1 1 40
> 2 2 2 50
> 2 3 3 60
>
> Am I doing something wrong or is this a bug with INSERT SELECT
> If this is the wrong list, please tell me where to post
>
> thanks
> fmardini


Actually, the more I look at this, the more confused I become.

What are you trying to achieve here? Are you just wanting to update
val2 (where id1 = 1) to (val1 where id1 = 2) + 100?

If so wouldn't a multi-table update with aliases be easier?

  Réponse avec citation
Vieux 18/10/2007, 12h22   #4
Captain Paralytic
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: bug with insert select?

On 18 Oct, 11:21, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On 18 Oct, 10:28, fmardini <f.mard...@gmail.com> wrote:
>
>
>
>
>
> > I think I might have found a bug with insert select when inserting
> > into the same table and using a composite primary key
> > I made the smallest example I could come up with

>
> > CREATE TABLE `t1` (
> > `id1` int(11) NOT NULL,
> > `id2` int(11) NOT NULL,
> > `val1` int(11) default '0',
> > `val2` int(11) default '0',
> > PRIMARY KEY (`id1`,`id2`)
> > ) ENGINE=InnoDB DEFAULT CHARSET=utf8

>
> > CREATE VIEW t1v AS SELECT * FROM t1

>
> > INSERT INTO t1 (`id1`, `id2`, `val1`, `val2`) VALUES (1, 1, 1, 10),
> > (1, 2, 2, 20), (1, 3, 3, 30), (2, 1, 1, 40), (2, 2, 2, 50), (2, 3, 3,
> > 60)

>
> > I want to insert into the table from itself
> > I use the view as a way to reference the selected row as opposed to
> > the found (duplicate) row (otherwise i get an ambiguous reference
> > error)

>
> > INSERT INTO t1
> > SELECT 1, id2, 0, 100
> > FROM t1v WHERE id1 = 2
> > ON DUPLICATE KEY UPDATE t1.val2 = t1v.val1 + 100

>
> > After executing the query, the contents of the table are

>
> > 1 1 1 103
> > 1 2 2 103
> > 1 3 3 103
> > 2 1 1 40
> > 2 2 2 50
> > 2 3 3 60

>
> > I was expecting the following

>
> > 1 1 1 101
> > 1 2 2 102
> > 1 3 3 103
> > 2 1 1 40
> > 2 2 2 50
> > 2 3 3 60

>
> > Am I doing something wrong or is this a bug with INSERT SELECT
> > If this is the wrong list, please tell me where to post

>
> > thanks
> > fmardini

>
> Actually, the more I look at this, the more confused I become.
>
> What are you trying to achieve here? Are you just wanting to update
> val2 (where id1 = 1) to (val1 where id1 = 2) + 100?
>
> If so wouldn't a multi-table update with aliases be easier?- Hide quoted text -
>
> - Show quoted text -


Since the val1 values for id1 = 2 are the same as those for id1 = 1,
it is not at all clear.

Please re-hash your sample data to make it clear what is required to
happen.

  Réponse avec citation
Vieux 18/10/2007, 12h27   #5
fmardini
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: bug with insert select?

On Oct 18, 12:54 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On 18 Oct, 10:28, fmardini <f.mard...@gmail.com> wrote:
>
> > I think I might have found a bug with insert select when inserting
> > into the same table and using a composite primary key
> > I made the smallest example I could come up with

>
> > CREATE TABLE `t1` (
> > `id1` int(11) NOT NULL,
> > `id2` int(11) NOT NULL,
> > `val1` int(11) default '0',
> > `val2` int(11) default '0',
> > PRIMARY KEY (`id1`,`id2`)
> > ) ENGINE=InnoDB DEFAULT CHARSET=utf8

>
> > CREATE VIEW t1v AS SELECT * FROM t1

>
> > INSERT INTO t1 (`id1`, `id2`, `val1`, `val2`) VALUES (1, 1, 1, 10),
> > (1, 2, 2, 20), (1, 3, 3, 30), (2, 1, 1, 40), (2, 2, 2, 50), (2, 3, 3,
> > 60)

>
> > I want to insert into the table from itself
> > I use the view as a way to reference the selected row as opposed to
> > the found (duplicate) row (otherwise i get an ambiguous reference
> > error)

>
> You wouldn't get the ambiguous reference error if you simply gave your
> table references unque aliases.
>


I tried using SELECT ... AS but it didn't work

> > INSERT INTO t1
> > SELECT 1, id2, 0, 100
> > FROM t1v WHERE id1 = 2
> > ON DUPLICATE KEY UPDATE t1.val2 = t1v.val1 + 100

>
> You are not using the complete composite primary key, so the last row
> encountered with the partial key in the WHERE clause will update the
> rows. This is not a bug, it is what you told it to do.
>


I think i use the complete composite key since the select statement
selects 1, id2, i might be missing something though
I still don't understand why does it use the last row

the select part return three rows
1 1 0 100
1 2 0 100
1 3 0 100

and all those rows are duplicates (based on the composite primary key)
thanks again for your

> You have posted sample data inserts and create statements so I will
> load it into a table so I can see what you want the transformation to
> look like.



  Réponse avec citation
Vieux 18/10/2007, 12h39   #6
fmardini
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: bug with insert select?

On Oct 18, 1:22 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On 18 Oct, 11:21, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
>
>
> > On 18 Oct, 10:28, fmardini <f.mard...@gmail.com> wrote:

>
> > > I think I might have found a bug with insert select when inserting
> > > into the same table and using a composite primary key
> > > I made the smallest example I could come up with

>
> > > CREATE TABLE `t1` (
> > > `id1` int(11) NOT NULL,
> > > `id2` int(11) NOT NULL,
> > > `val1` int(11) default '0',
> > > `val2` int(11) default '0',
> > > PRIMARY KEY (`id1`,`id2`)
> > > ) ENGINE=InnoDB DEFAULT CHARSET=utf8

>
> > > CREATE VIEW t1v AS SELECT * FROM t1

>
> > > INSERT INTO t1 (`id1`, `id2`, `val1`, `val2`) VALUES (1, 1, 1, 10),
> > > (1, 2, 2, 20), (1, 3, 3, 30), (2, 1, 1, 40), (2, 2, 2, 50), (2, 3, 3,
> > > 60)

>
> > > I want to insert into the table from itself
> > > I use the view as a way to reference the selected row as opposed to
> > > the found (duplicate) row (otherwise i get an ambiguous reference
> > > error)

>
> > > INSERT INTO t1
> > > SELECT 1, id2, 0, 100
> > > FROM t1v WHERE id1 = 2
> > > ON DUPLICATE KEY UPDATE t1.val2 = t1v.val1 + 100

>
> > > After executing the query, the contents of the table are

>
> > > 1 1 1 103
> > > 1 2 2 103
> > > 1 3 3 103
> > > 2 1 1 40
> > > 2 2 2 50
> > > 2 3 3 60

>
> > > I was expecting the following

>
> > > 1 1 1 101
> > > 1 2 2 102
> > > 1 3 3 103
> > > 2 1 1 40
> > > 2 2 2 50
> > > 2 3 3 60

>
> > > Am I doing something wrong or is this a bug with INSERT SELECT
> > > If this is the wrong list, please tell me where to post

>
> > > thanks
> > > fmardini

>
> > Actually, the more I look at this, the more confused I become.

>
> > What are you trying to achieve here? Are you just wanting to update
> > val2 (where id1 = 1) to (val1 where id1 = 2) + 100?

>
> > If so wouldn't a multi-table update with aliases be easier?- Hide quoted text -

>
> > - Show quoted text -

>
> Since the val1 values for id1 = 2 are the same as those for id1 = 1,
> it is not at all clear.
>
> Please re-hash your sample data to make it clear what is required to
> happen.


Ok this table is supposed to track a relation between two kinds of
objects, and the composite primary key is made up of the ids of the
two related objects
What i am trying to do is create a relation between object1 and all
objects object2 is related to, but if the relation already exists i
have to update some parameters in the relation (the on duplicate key
thing)

  Réponse avec citation
Vieux 18/10/2007, 14h17   #7
Captain Paralytic
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: bug with insert select?

On 18 Oct, 11:39, fmardini <f.mard...@gmail.com> wrote:
> On Oct 18, 1:22 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
>
>
>
>
> > On 18 Oct, 11:21, Captain Paralytic <paul_laut...@yahoo.com> wrote:

>
> > > On 18 Oct, 10:28, fmardini <f.mard...@gmail.com> wrote:

>
> > > > I think I might have found a bug with insert select when inserting
> > > > into the same table and using a composite primary key
> > > > I made the smallest example I could come up with

>
> > > > CREATE TABLE `t1` (
> > > > `id1` int(11) NOT NULL,
> > > > `id2` int(11) NOT NULL,
> > > > `val1` int(11) default '0',
> > > > `val2` int(11) default '0',
> > > > PRIMARY KEY (`id1`,`id2`)
> > > > ) ENGINE=InnoDB DEFAULT CHARSET=utf8

>
> > > > CREATE VIEW t1v AS SELECT * FROM t1

>
> > > > INSERT INTO t1 (`id1`, `id2`, `val1`, `val2`) VALUES (1, 1, 1, 10),
> > > > (1, 2, 2, 20), (1, 3, 3, 30), (2, 1, 1, 40), (2, 2, 2, 50), (2, 3, 3,
> > > > 60)

>
> > > > I want to insert into the table from itself
> > > > I use the view as a way to reference the selected row as opposed to
> > > > the found (duplicate) row (otherwise i get an ambiguous reference
> > > > error)

>
> > > > INSERT INTO t1
> > > > SELECT 1, id2, 0, 100
> > > > FROM t1v WHERE id1 = 2
> > > > ON DUPLICATE KEY UPDATE t1.val2 = t1v.val1 + 100

>
> > > > After executing the query, the contents of the table are

>
> > > > 1 1 1 103
> > > > 1 2 2 103
> > > > 1 3 3 103
> > > > 2 1 1 40
> > > > 2 2 2 50
> > > > 2 3 3 60

>
> > > > I was expecting the following

>
> > > > 1 1 1 101
> > > > 1 2 2 102
> > > > 1 3 3 103
> > > > 2 1 1 40
> > > > 2 2 2 50
> > > > 2 3 3 60

>
> > > > Am I doing something wrong or is this a bug with INSERT SELECT
> > > > If this is the wrong list, please tell me where to post

>
> > > > thanks
> > > > fmardini

>
> > > Actually, the more I look at this, the more confused I become.

>
> > > What are you trying to achieve here? Are you just wanting to update
> > > val2 (where id1 = 1) to (val1 where id1 = 2) + 100?

>
> > > If so wouldn't a multi-table update with aliases be easier?- Hide quoted text -

>
> > > - Show quoted text -

>
> > Since the val1 values for id1 = 2 are the same as those for id1 = 1,
> > it is not at all clear.

>
> > Please re-hash your sample data to make it clear what is required to
> > happen.

>
> Ok this table is supposed to track a relation between two kinds of
> objects, and the composite primary key is made up of the ids of the
> two related objects
> What i am trying to do is create a relation between object1 and all
> objects object2 is related to, but if the relation already exists i
> have to update some parameters in the relation (the on duplicate key
> thing)- Hide quoted text -
>
> - Show quoted text -


Hmmm, I changed your sample data to make it plainer what was coming
from where, and changed the query to use an alias instead of a view,
once again to make it obvious what was coming from where:

INSERT INTO t1( `id1` , `id2` , `val1` , `val2` )
VALUES ( 1, 1, 1, 10 ) , ( 1, 2, 2, 20 ) , ( 1, 3, 3, 30 ) , ( 2, 1,
4, 40 ) , ( 2, 2, 5, 50 ) , ( 2, 3, 6, 60 )

INSERT INTO t1
SELECT 1, a2.id2, 0, 100
FROM t1 a2 WHERE a2.id1 = 2
ON DUPLICATE KEY UPDATE t1.val2 = a2.val1 + 100

Now, I tried it with a non-composite key and the effect is the same. I
don't think this is anything to do with composite keys.

It seems as if it logs the need to perform an update and then does
them all at the end, at which time a2.val1 has the value 6.

  Réponse avec citation
Vieux 18/10/2007, 14h24   #8
fmardini
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: bug with insert select?

On Oct 18, 3:17 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On 18 Oct, 11:39, fmardini <f.mard...@gmail.com> wrote:
>
>
>
> > On Oct 18, 1:22 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:

>
> > > On 18 Oct, 11:21, Captain Paralytic <paul_laut...@yahoo.com> wrote:

>
> > > > On 18 Oct, 10:28, fmardini <f.mard...@gmail.com> wrote:

>
> > > > > I think I might have found a bug with insert select when inserting
> > > > > into the same table and using a composite primary key
> > > > > I made the smallest example I could come up with

>
> > > > > CREATE TABLE `t1` (
> > > > > `id1` int(11) NOT NULL,
> > > > > `id2` int(11) NOT NULL,
> > > > > `val1` int(11) default '0',
> > > > > `val2` int(11) default '0',
> > > > > PRIMARY KEY (`id1`,`id2`)
> > > > > ) ENGINE=InnoDB DEFAULT CHARSET=utf8

>
> > > > > CREATE VIEW t1v AS SELECT * FROM t1

>
> > > > > INSERT INTO t1 (`id1`, `id2`, `val1`, `val2`) VALUES (1, 1, 1, 10),
> > > > > (1, 2, 2, 20), (1, 3, 3, 30), (2, 1, 1, 40), (2, 2, 2, 50), (2, 3, 3,
> > > > > 60)

>
> > > > > I want to insert into the table from itself
> > > > > I use the view as a way to reference the selected row as opposed to
> > > > > the found (duplicate) row (otherwise i get an ambiguous reference
> > > > > error)

>
> > > > > INSERT INTO t1
> > > > > SELECT 1, id2, 0, 100
> > > > > FROM t1v WHERE id1 = 2
> > > > > ON DUPLICATE KEY UPDATE t1.val2 = t1v.val1 + 100

>
> > > > > After executing the query, the contents of the table are

>
> > > > > 1 1 1 103
> > > > > 1 2 2 103
> > > > > 1 3 3 103
> > > > > 2 1 1 40
> > > > > 2 2 2 50
> > > > > 2 3 3 60

>
> > > > > I was expecting the following

>
> > > > > 1 1 1 101
> > > > > 1 2 2 102
> > > > > 1 3 3 103
> > > > > 2 1 1 40
> > > > > 2 2 2 50
> > > > > 2 3 3 60

>
> > > > > Am I doing something wrong or is this a bug with INSERT SELECT
> > > > > If this is the wrong list, please tell me where to post

>
> > > > > thanks
> > > > > fmardini

>
> > > > Actually, the more I look at this, the more confused I become.

>
> > > > What are you trying to achieve here? Are you just wanting to update
> > > > val2 (where id1 = 1) to (val1 where id1 = 2) + 100?

>
> > > > If so wouldn't a multi-table update with aliases be easier?- Hide quoted text -

>
> > > > - Show quoted text -

>
> > > Since the val1 values for id1 = 2 are the same as those for id1 = 1,
> > > it is not at all clear.

>
> > > Please re-hash your sample data to make it clear what is required to
> > > happen.

>
> > Ok this table is supposed to track a relation between two kinds of
> > objects, and the composite primary key is made up of the ids of the
> > two related objects
> > What i am trying to do is create a relation between object1 and all
> > objects object2 is related to, but if the relation already exists i
> > have to update some parameters in the relation (the on duplicate key
> > thing)- Hide quoted text -

>
> > - Show quoted text -

>
> Hmmm, I changed your sample data to make it plainer what was coming
> from where, and changed the query to use an alias instead of a view,
> once again to make it obvious what was coming from where:
>
> INSERT INTO t1( `id1` , `id2` , `val1` , `val2` )
> VALUES ( 1, 1, 1, 10 ) , ( 1, 2, 2, 20 ) , ( 1, 3, 3, 30 ) , ( 2, 1,
> 4, 40 ) , ( 2, 2, 5, 50 ) , ( 2, 3, 6, 60 )
>
> INSERT INTO t1
> SELECT 1, a2.id2, 0, 100
> FROM t1 a2 WHERE a2.id1 = 2
> ON DUPLICATE KEY UPDATE t1.val2 = a2.val1 + 100
>
> Now, I tried it with a non-composite key and the effect is the same. I
> don't think this is anything to do with composite keys.
>
> It seems as if it logs the need to perform an update and then does
> them all at the end, at which time a2.val1 has the value 6.


yeah, to me it looks like a bug
i really appreciate your assistance

fmardini

  Réponse avec citation
Vieux 18/10/2007, 14h42   #9
Captain Paralytic
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: bug with insert select?

On 18 Oct, 13:24, fmardini <f.mard...@gmail.com> wrote:
> On Oct 18, 3:17 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
>
>
>
>
>
> > On 18 Oct, 11:39, fmardini <f.mard...@gmail.com> wrote:

>
> > > On Oct 18, 1:22 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:

>
> > > > On 18 Oct, 11:21, Captain Paralytic <paul_laut...@yahoo.com> wrote:

>
> > > > > On 18 Oct, 10:28, fmardini <f.mard...@gmail.com> wrote:

>
> > > > > > I think I might have found a bug with insert select when inserting
> > > > > > into the same table and using a composite primary key
> > > > > > I made the smallest example I could come up with

>
> > > > > > CREATE TABLE `t1` (
> > > > > > `id1` int(11) NOT NULL,
> > > > > > `id2` int(11) NOT NULL,
> > > > > > `val1` int(11) default '0',
> > > > > > `val2` int(11) default '0',
> > > > > > PRIMARY KEY (`id1`,`id2`)
> > > > > > ) ENGINE=InnoDB DEFAULT CHARSET=utf8

>
> > > > > > CREATE VIEW t1v AS SELECT * FROM t1

>
> > > > > > INSERT INTO t1 (`id1`, `id2`, `val1`, `val2`) VALUES (1, 1, 1, 10),
> > > > > > (1, 2, 2, 20), (1, 3, 3, 30), (2, 1, 1, 40), (2, 2, 2, 50), (2, 3, 3,
> > > > > > 60)

>
> > > > > > I want to insert into the table from itself
> > > > > > I use the view as a way to reference the selected row as opposed to
> > > > > > the found (duplicate) row (otherwise i get an ambiguous reference
> > > > > > error)

>
> > > > > > INSERT INTO t1
> > > > > > SELECT 1, id2, 0, 100
> > > > > > FROM t1v WHERE id1 = 2
> > > > > > ON DUPLICATE KEY UPDATE t1.val2 = t1v.val1 + 100

>
> > > > > > After executing the query, the contents of the table are

>
> > > > > > 1 1 1 103
> > > > > > 1 2 2 103
> > > > > > 1 3 3 103
> > > > > > 2 1 1 40
> > > > > > 2 2 2 50
> > > > > > 2 3 3 60

>
> > > > > > I was expecting the following

>
> > > > > > 1 1 1 101
> > > > > > 1 2 2 102
> > > > > > 1 3 3 103
> > > > > > 2 1 1 40
> > > > > > 2 2 2 50
> > > > > > 2 3 3 60

>
> > > > > > Am I doing something wrong or is this a bug with INSERT SELECT
> > > > > > If this is the wrong list, please tell me where to post

>
> > > > > > thanks
> > > > > > fmardini

>
> > > > > Actually, the more I look at this, the more confused I become.

>
> > > > > What are you trying to achieve here? Are you just wanting to update
> > > > > val2 (where id1 = 1) to (val1 where id1 = 2) + 100?

>
> > > > > If so wouldn't a multi-table update with aliases be easier?- Hide quoted text -

>
> > > > > - Show quoted text -

>
> > > > Since the val1 values for id1 = 2 are the same as those for id1 = 1,
> > > > it is not at all clear.

>
> > > > Please re-hash your sample data to make it clear what is required to
> > > > happen.

>
> > > Ok this table is supposed to track a relation between two kinds of
> > > objects, and the composite primary key is made up of the ids of the
> > > two related objects
> > > What i am trying to do is create a relation between object1 and all
> > > objects object2 is related to, but if the relation already exists i
> > > have to update some parameters in the relation (the on duplicate key
> > > thing)- Hide quoted text -

>
> > > - Show quoted text -

>
> > Hmmm, I changed your sample data to make it plainer what was coming
> > from where, and changed the query to use an alias instead of a view,
> > once again to make it obvious what was coming from where:

>
> > INSERT INTO t1( `id1` , `id2` , `val1` , `val2` )
> > VALUES ( 1, 1, 1, 10 ) , ( 1, 2, 2, 20 ) , ( 1, 3, 3, 30 ) , ( 2, 1,
> > 4, 40 ) , ( 2, 2, 5, 50 ) , ( 2, 3, 6, 60 )

>
> > INSERT INTO t1
> > SELECT 1, a2.id2, 0, 100
> > FROM t1 a2 WHERE a2.id1 = 2
> > ON DUPLICATE KEY UPDATE t1.val2 = a2.val1 + 100

>
> > Now, I tried it with a non-composite key and the effect is the same. I
> > don't think this is anything to do with composite keys.

>
> > It seems as if it logs the need to perform an update and then does
> > them all at the end, at which time a2.val1 has the value 6.

>
> yeah, to me it looks like a bug
> i really appreciate your assistance
>
> fmardini- Hide quoted text -
>
> - Show quoted text -


Hmm, I may have thought of another way of accomplishing this.

Could you provide a before and after table of what you expect to see.
The before table should require an insert as well as an update and the
sample data should make it obvious what data is coming from what row
(as in my sample).

So 5 rows in the before table and 6 in the after one. Just to check
that I have really sussed what you expect to see.

  Réponse avec citation
Vieux 18/10/2007, 15h27   #10
fmardini
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: bug with insert select?

On Oct 18, 3:42 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On 18 Oct, 13:24, fmardini <f.mard...@gmail.com> wrote:
>
>
>
> > On Oct 18, 3:17 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:

>
> > > On 18 Oct, 11:39, fmardini <f.mard...@gmail.com> wrote:

>
> > > > On Oct 18, 1:22 pm, Captain Paralytic <paul_laut...@yahoo.com> wrote:

>
> > > > > On 18 Oct, 11:21, Captain Paralytic <paul_laut...@yahoo.com> wrote:

>
> > > > > > On 18 Oct, 10:28, fmardini <f.mard...@gmail.com> wrote:

>
> > > > > > > I think I might have found a bug with insert select when inserting
> > > > > > > into the same table and using a composite primary key
> > > > > > > I made the smallest example I could come up with

>
> > > > > > > CREATE TABLE `t1` (
> > > > > > > `id1` int(11) NOT NULL,
> > > > > > > `id2` int(11) NOT NULL,
> > > > > > > `val1` int(11) default '0',
> > > > > > > `val2` int(11) default '0',
> > > > > > > PRIMARY KEY (`id1`,`id2`)
> > > > > > > ) ENGINE=InnoDB DEFAULT CHARSET=utf8

>
> > > > > > > CREATE VIEW t1v AS SELECT * FROM t1

>
> > > > > > > INSERT INTO t1 (`id1`, `id2`, `val1`, `val2`) VALUES (1, 1, 1, 10),
> > > > > > > (1, 2, 2, 20), (1, 3, 3, 30), (2, 1, 1, 40), (2, 2, 2, 50), (2, 3, 3,
> > > > > > > 60)

>
> > > > > > > I want to insert into the table from itself
> > > > > > > I use the view as a way to reference the selected row as opposed to
> > > > > > > the found (duplicate) row (otherwise i get an ambiguous reference
> > > > > > > error)

>
> > > > > > > INSERT INTO t1
> > > > > > > SELECT 1, id2, 0, 100
> > > > > > > FROM t1v WHERE id1 = 2
> > > > > > > ON DUPLICATE KEY UPDATE t1.val2 = t1v.val1 + 100

>
> > > > > > > After executing the query, the contents of the table are

>
> > > > > > > 1 1 1 103
> > > > > > > 1 2 2 103
> > > > > > > 1 3 3 103
> > > > > > > 2 1 1 40
> > > > > > > 2 2 2 50
> > > > > > > 2 3 3 60

>
> > > > > > > I was expecting the following

>
> > > > > > > 1 1 1 101
> > > > > > > 1 2 2 102
> > > > > > > 1 3 3 103
> > > > > > > 2 1 1 40
> > > > > > > 2 2 2 50
> > > > > > > 2 3 3 60

>
> > > > > > > Am I doing something wrong or is this a bug with INSERT SELECT
> > > > > > > If this is the wrong list, please tell me where to post

>
> > > > > > > thanks
> > > > > > > fmardini

>
> > > > > > Actually, the more I look at this, the more confused I become.

>
> > > > > > What are you trying to achieve here? Are you just wanting to update
> > > > > > val2 (where id1 = 1) to (val1 where id1 = 2) + 100?

>
> > > > > > If so wouldn't a multi-table update with aliases be easier?- Hide quoted text -

>
> > > > > > - Show quoted text -

>
> > > > > Since the val1 values for id1 = 2 are the same as those for id1 = 1,
> > > > > it is not at all clear.

>
> > > > > Please re-hash your sample data to make it clear what is required to
> > > > > happen.

>
> > > > Ok this table is supposed to track a relation between two kinds of
> > > > objects, and the composite primary key is made up of the ids of the
> > > > two related objects
> > > > What i am trying to do is create a relation between object1 and all
> > > > objects object2 is related to, but if the relation already exists i
> > > > have to update some parameters in the relation (the on duplicate key
> > > > thing)- Hide quoted text -

>
> > > > - Show quoted text -

>
> > > Hmmm, I changed your sample data to make it plainer what was coming
> > > from where, and changed the query to use an alias instead of a view,
> > > once again to make it obvious what was coming from where:

>
> > > INSERT INTO t1( `id1` , `id2` , `val1` , `val2` )
> > > VALUES ( 1, 1, 1, 10 ) , ( 1, 2, 2, 20 ) , ( 1, 3, 3, 30 ) , ( 2, 1,
> > > 4, 40 ) , ( 2, 2, 5, 50 ) , ( 2, 3, 6, 60 )

>
> > > INSERT INTO t1
> > > SELECT 1, a2.id2, 0, 100
> > > FROM t1 a2 WHERE a2.id1 = 2
> > > ON DUPLICATE KEY UPDATE t1.val2 = a2.val1 + 100

>
> > > Now, I tried it with a non-composite key and the effect is the same. I
> > > don't think this is anything to do with composite keys.

>
> > > It seems as if it logs the need to perform an update and then does
> > > them all at the end, at which time a2.val1 has the value 6.

>
> > yeah, to me it looks like a bug
> > i really appreciate your assistance

>
> > fmardini- Hide quoted text -

>
> > - Show quoted text -

>
> Hmm, I may have thought of another way of accomplishing this.
>
> Could you provide a before and after table of what you expect to see.
> The before table should require an insert as well as an update and the
> sample data should make it obvious what data is coming from what row
> (as in my sample).
>
> So 5 rows in the before table and 6 in the after one. Just to check
> that I have really sussed what you expect to see.


Thanks,

working with your data, if you remove the value ( 1, 3, 3, 30 ) thus
having

INSERT INTO t1( `id1` , `id2` , `val1` , `val2` )
VALUES ( 1, 1, 1, 10 ) , ( 1, 2, 2, 20 ) , ( 1, 3, 3, 30 ) , ( 2, 1,
4, 40 ) , ( 2, 2, 5, 50 ) , ( 2, 3, 6, 60 )

and then running the query u provided we get

1 1 1 106
1 2 2 106
1 3 0 100
2 1 4 40
2 2 5 50
2 3 6 60

but what i would expect is

1 1 1 104
1 2 2 105
1 3 0 100
2 1 4 40
2 2 5 50
2 3 6 60

thanks

  Réponse avec citation
Vieux 18/10/2007, 23h47   #11
Paul Lautman
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: bug with insert select?

OK, try this:

INSERT INTO t1
(id1, id2, val1, val2)
SELECT
1,
a1.id2,
0,
a1.val2
FROM t1 a1
LEFT JOIN t1 a2 ON a2.id1 = 1
AND a1.id2 = a2.id2
WHERE a1.id1 = 2 AND a2.id1 IS NULL
UNION
SELECT
1,
a1.id2,
a1.val1,
a1.val1 + 100
FROM t1 a1
LEFT JOIN t1 a2 ON a2.id1 = 1
AND a1.id2 = a2.id2
WHERE a1.id1 = 2 AND a2.id1 IS NOT NULL
ON DUPLICATE KEY UPDATE
t1.val2 = VALUES(val2)


  Réponse avec citation
Réponse


Outils de la discussion

Règles de messages
Vous ne pouvez pas créer de nouvelles discussions
Vous ne pouvez pas envoyer des réponses
Vous ne pouvez pas envoyer des pièces jointes
Vous ne pouvez pas modifier vos messages

Les balises BB sont activées : oui
Les smileys sont activés : oui
La balise [IMG] est activée : oui
Le code HTML peut être employé : non
Trackbacks are oui
Pingbacks are oui
Refbacks are oui


Fuseau horaire GMT +1. Il est actuellement 01h06.


Édité par : vBulletin® version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0 RC5 Tous droits réservés.
Version française #16 par l'association vBulletin francophone
PHWinfo est un site Éducation Sans Frontières ©2000-2008
Ad Management by RedTyger
©Tous droits réservés par les parties respectives
Page generated in 0,38867 seconds with 19 queries