bug (feature?) wrt INSERT IGNORE & LAST_INSERT_ID

bug (feature?) wrt INSERT IGNORE & LAST_INSERT_ID

am 30.10.2002 10:10:43 von Werner Stuerenburg

This Report was made using the WinMySQLAdmin 1.4 Tool

30.10.02 09:46:54

Description : bug (feature?) found by mark at wildrhino
dot com according to comment section in
http://php3.de/manual/de/function.mysql-insert-id.php
tested with 3.23.31 - it is still there in
4.0.2 as tested by myself
The point is: given the construction of the
example, you would expect to get no auto_inc
value for the second value due to a unique
key error - so I'd consider this a bug
rather than a feature
How-To-Repeat : run insertIgnore.sql like
mysql test < insertIgnore.sql > insertIgnoreRes.sql
and get insertIgnoreRes.sql

__________________________________________________________
insertIgnore.sql

CREATE TABLE test
(
ID MEDIUMINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
stuff VARCHAR(255),
UNIQUE stuff (stuff)
)
;

SELECT LAST_INSERT_ID();

INSERT IGNORE INTO test (stuff) VALUES ('some_stuff');

SELECT LAST_INSERT_ID();

INSERT IGNORE INTO test (stuff) VALUES ('some_stuff');

SELECT LAST_INSERT_ID();

SELECT * FROM test WHERE id=2;

__________________________________________________________
insertIgnoreRes.sql

last_insert_id()
0
last_insert_id()
1
last_insert_id()
2


Fix :
Synopsis :
Submitter-Id :
Originator : Werner@mysql.com
Organization : MySQL AB
MySQL support : [none]
Severity : [non-critical]
Priority : [low]
Category : [mysqld]
Class : [ sw-bug]
OS Platform : Windows 98
Machine description:
Compiler : VC++ 6.0
Architecture : i686
Total Memory : 261324 KB RAM

My.ini File

[mysqld]
set-variable=lower_case_table_names=0
set-variable=table_cache=180
basedir=C:/APACHE/MYSQL
datadir=C:/APACHE/MYSQL/data
set-variable=max_allowed_packet=16M
set-variable=flush_time=60
server-id=99
log-bin=C:/APACHE/MYSQL/data/rembrandt-bin.299
log-slow-queries=C:/APACHE/MYSQL/data/rembrandt-slow12.log
set-variable=long_query_time=1
log-long-format

Server Status Values

Server Info 4.0.2-alpha-max-log
Host Info localhost via TCP/IP
Client Info 4.0.2-alpha
Proto Info 10
Aborted_clients 0
Aborted_connects 0
Bytes_received 0
Bytes_sent 0
Com_admin_commands 15
Com_alter_table 0
Com_analyze 0
Com_backup_table 0
Com_begin 0
Com_change_db 380
Com_change_master 0
Com_check 0
Com_commit 0
Com_create_db 0
Com_create_function 0
Com_create_index 0
Com_create_table 1
Com_delete 0
Com_delete_multi 0
Com_drop_db 0
Com_drop_function 0
Com_drop_index 0
Com_drop_table 0
Com_flush 0
Com_grant 0
Com_ha_close 0
Com_ha_open 0
Com_ha_read 0
Com_insert 2
Com_insert_select 0
Com_kill 0
Com_load 0
Com_load_master_data 0
Com_load_master_table 0
Com_lock_tables 0
Com_optimize 0
Com_purge 0
Com_rename_table 0
Com_repair 0
Com_replace 32
Com_replace_select 0
Com_reset 0
Com_restore_table 0
Com_revoke 0
Com_rollback 0
Com_select 540
Com_set_option 0
Com_show_binlog_events 0
Com_show_binlogs 0
Com_show_create 0
Com_show_databases 3
Com_show_fields 3
Com_show_grants 0
Com_show_keys 0
Com_show_logs 0
Com_show_master_status 0
Com_show_new_master 0
Com_show_open_tables 0
Com_show_processlist 1
Com_show_slave_hosts 0
Com_show_slave_status 0
Com_show_status 1
Com_show_tables 30
Com_show_variables 1
Com_slave_start 0
Com_slave_stop 0
Com_truncate 0
Com_unlock_tables 0
Com_update 6
Connections 42
Created_tmp_disk_tables 6
Created_tmp_tables 75
Created_tmp_files 0
Delayed_insert_threads 0
Delayed_writes 0
Delayed_errors 0
Flush_commands 1
Handler_commit 0
Handler_delete 0
Handler_read_first 67
Handler_read_key 1153
Handler_read_next 1844
Handler_read_prev 0
Handler_read_rnd 216
Handler_read_rnd_next 14453
Handler_rollback 2
Handler_update 34
Handler_write 2098
Key_blocks_used 846
Key_read_requests 5516
Key_reads 843
Key_write_requests 373
Key_writes 582
Max_used_connections 3
Not_flushed_key_blocks 0
Not_flushed_delayed_rows 0
Open_tables 0
Open_files 2
Open_streams 0
Opened_tables 578
Questions 1040
Qcache_queries_in_cache 0
Qcache_inserts 0
Qcache_hits 0
Qcache_not_cached 0
Qcache_free_memory 0
Qcache_free_blocks 0
Qcache_total_blocks 0
Rpl_status NULL
Select_full_join 0
Select_full_range_join 0
Select_range 115
Select_range_check 0
Select_scan 67
Slave_open_temp_tables 0
Slave_running OFF
Slow_launch_threads 0
Slow_queries 67
Sort_merge_passes 0
Sort_range 6
Sort_rows 188
Sort_scan 81
Table_locks_immediate 1059
Table_locks_waited 0
Threads_cached 0
Threads_created 41
Threads_connected 1
Threads_running 1
Uptime 2588

Variables Values

back_log 50
basedir C:\APACHE\MYSQL\
bdb_cache_size 8388600
bdb_log_buffer_size 92160
bdb_home C:\APACHE\MYSQL\data\
bdb_max_lock 10000
bdb_logdir
bdb_shared_data OFF
bdb_tmpdir C:\WINDOWS\TEMP\
bdb_version Sleepycat Software: Berkeley DB 3.2.9a: (July 5, 2002)
binlog_cache_size 32768
character_set latin1
character_sets latin1 big5 czech euc_kr gb2312 gbk latin1_de sjis tis620 ujis dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251 danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr greek win1250 croat cp1257 latin5
concurrent_insert OFF
connect_timeout 5
datadir C:\APACHE\MYSQL\data\
delay_key_write OFF
delayed_insert_limit 100
delayed_insert_timeout 300
delayed_queue_size 1000
flush OFF
flush_time 60
ft_min_word_len 4
ft_max_word_len 254
ft_max_word_len_for_sort 20
ft_boolean_syntax + -><()~*:""&|
have_bdb YES
have_innodb YES
have_isam YES
have_raid NO
have_symlink YES
have_openssl NO
have_query_cache YES
init_file
innodb_additional_mem_pool_size 1048576
innodb_buffer_pool_size 8388608
innodb_data_file_path ibdata1:10M:autoextend
innodb_data_home_dir
innodb_file_io_threads 4
innodb_force_recovery 0
innodb_thread_concurrency 8
innodb_flush_log_at_trx_commit OFF
innodb_fast_shutdown ON
innodb_flush_method
innodb_lock_wait_timeout 50
innodb_log_arch_dir
innodb_log_archive OFF
innodb_log_buffer_size 1048576
innodb_log_file_size 5242880
innodb_log_files_in_group 2
innodb_log_group_home_dir .\
innodb_mirrored_log_groups 1
interactive_timeout 28800
join_buffer_size 131072
key_buffer_size 8388600
language C:\APACHE\MYSQL\share\english\
large_files_support ON
log OFF
log_update OFF
log_bin ON
log_slave_updates OFF
log_slow_queries ON
long_query_time 1
low_priority_updates OFF
lower_case_table_names 0
max_allowed_packet 16776192
max_binlog_cache_size 4294967295
max_binlog_size 1073741824
max_connections 100
max_connect_errors 10
max_delayed_threads 20
max_heap_table_size 16777216
max_join_size 4294967295
max_sort_length 1024
max_user_connections 0
max_tmp_tables 32
max_write_lock_count 4294967295
myisam_bulk_insert_tree_size 8388608
myisam_max_extra_sort_file_size 256
myisam_max_sort_file_size 2047
myisam_recover_options OFF
myisam_sort_buffer_size 8388608
net_buffer_length 16384
net_read_timeout 30
net_retry_count 10
net_write_timeout 60
open_files_limit 0
pid_file C:\APACHE\MYSQL\data\rembrandt.pid
port 3306
protocol_version 10
record_buffer 131072
record_rnd_buffer 131072
rpl_recovery_rank 0
query_buffer_size 0
query_cache_limit 1048576
query_cache_size 0
query_cache_startup_type 1
safe_show_database OFF
server_id 99
slave_net_timeout 3600
skip_locking ON
skip_networking OFF
skip_show_database OFF
slow_launch_time 2
socket MySQL
sort_buffer 2097144
sql_mode 0
table_cache 180
table_type MYISAM
thread_cache_size 0
thread_stack 65536
transaction_isolation READ-COMMITTED
timezone (MEZ) Mitteleuropäische Zeit
tmp_table_size 33554432
tmpdir C:\WINDOWS\TEMP\
version 4.0.2-alpha-max-log
wait_timeout 28800

Last Lines from Err File

C:/APACHE/MYSQL/bin/mysqld-max.exe: ready for connections
021030 9:03:55 InnoDB: Started
C:/APACHE/MYSQL/bin/mysqld-max.exe: ready for connections
021029 23:34:51 InnoDB: Started
C:/APACHE/MYSQL/bin/mysqld-max.exe: ready for connections
021029 22:35:46 InnoDB: Started
C:/APACHE/MYSQL/bin/mysqld-max.exe: ready for connections
021029 21:50:42 InnoDB: Started
C:/APACHE/MYSQL/bin/mysqld-max.exe: ready for connections

021029 15:12:27 C:/APACHE/MYSQL/bin/mysqld-max.exe: Shutdown Complete
021029 15:12:27 InnoDB: Shutdown completed
021029 15:12:21 InnoDB: Starting shutdown...

021029 15:12:21 C:/APACHE/MYSQL/bin/mysqld-max.exe: Normal shutdown



Mit freundlichen Grüßen
Werner Stürenburg

--
MySQL schlägt Microsoft:
http://www.eweek.com/article/0,3658,s=708&a=23115,00.asp
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Dr.math. W. Stürenburg
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB/GmbH, Consultant, Trainer
/_/ /_/\_, /___/\___\_\___/ Bielefeld, Germany
<___/ www.mysql.com +49-5774-5115-74 +49-172-938 0238


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12875@lists.mysql.com
To unsubscribe, e-mail

Re: bug (feature?) wrt INSERT IGNORE & LAST_INSERT_ID

am 30.10.2002 16:25:39 von Benjamin Pflugmann

Hello.

On Wed 2002-10-30 at 10:10:43 +0100, werner@mysql.com wrote:
> This Report was made using the WinMySQLAdmin 1.4 Tool
>
> 30.10.02 09:46:54
>
> Description : bug (feature?) found by mark at wildrhino
> dot com according to comment section in
> http://php3.de/manual/de/function.mysql-insert-id.php
> tested with 3.23.31 - it is still there in
> 4.0.2 as tested by myself
> The point is: given the construction of the
> example, you would expect to get no auto_inc
> value for the second value due to a unique
> key error - so I'd consider this a bug
> rather than a feature
> How-To-Repeat : run insertIgnore.sql like
> mysql test < insertIgnore.sql > insertIgnoreRes.sql
> and get insertIgnoreRes.sql

This is one of the technical restrictions of using INSERT DELAYED and
documented accordingly:

http://www.mysql.com/doc/en/INSERT_DELAYED.html


Regards,

Benjamin.


--
benjamin-mysql@pflugmann.de

------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12876@lists.mysql.com
To unsubscribe, e-mail

Re: bug (feature?) wrt INSERT IGNORE & LAST_INSERT_ID

am 30.10.2002 17:49:55 von Werner Stuerenburg

Hallo Benjamin!

BLUSH!!! Poor me, embarrassed once more! Better take time to read
the manual - well, this way I'll certainly learn!

Benjamin Pflugmann schrieb am Mittwoch, 30. Oktober 2002, 16:25:39:

> Hello.

> On Wed 2002-10-30 at 10:10:43 +0100, werner@mysql.com wrote:
>> This Report was made using the WinMySQLAdmin 1.4 Tool
>>
>> 30.10.02 09:46:54
>>
>> Description : bug (feature?) found by mark at wildrhino
>> dot com according to comment section in
>> http://php3.de/manual/de/function.mysql-insert-id.php
>> tested with 3.23.31 - it is still there in
>> 4.0.2 as tested by myself
>> The point is: given the construction of the
>> example, you would expect to get no auto_inc
>> value for the second value due to a unique
>> key error - so I'd consider this a bug
>> rather than a feature
>> How-To-Repeat : run insertIgnore.sql like
>> mysql test < insertIgnore.sql > insertIgnoreRes.sql
>> and get insertIgnoreRes.sql

> This is one of the technical restrictions of using INSERT DELAYED and
> documented accordingly:

> http://www.mysql.com/doc/en/INSERT_DELAYED.html


> Regards,

> Benjamin.





Mit freundlichen Grüßen
Werner Stürenburg

--
MySQL schlägt Microsoft:
http://www.eweek.com/article/0,3658,s=708&a=23115,00.asp
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Dr.math. W. Stürenburg
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB/GmbH, Consultant, Trainer
/_/ /_/\_, /___/\___\_\___/ Bielefeld, Germany
<___/ www.mysql.com +49-5744-5115-74 +49-172-938 0238


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12877@lists.mysql.com
To unsubscribe, e-mail

Re: bug (feature?) wrt INSERT IGNORE & LAST_INSERT_ID

am 30.10.2002 19:24:24 von Werner Stuerenburg

Hallo Benjamin!



> This is one of the technical restrictions of using INSERT DELAYED and
> documented accordingly:

> http://www.mysql.com/doc/en/INSERT_DELAYED.html

Sorry, I don't understand: we don't do any DELAYED stuff here.

Also, the return value of the autoincrement value IS meaningful
although there should be none. We talk about IGNORE here, which
doesn't relate directly to DELAYED, if I am correct.

IGNORE should ignore the error here, but should it output the
autoincrement value? It does not write the auto_increment value,
though, so this is rather a cosmetical question. We better forget
about it soon.

I understand the value has to be created before the insert, and
when the insert fails, it is still there but isn't written, so
the next insert will get this same value. It could be destroyed
after the error occurs to keep picky people quiet...

Mit freundlichen Grüßen
Werner Stürenburg

--
MySQL schlägt Microsoft:
http://www.eweek.com/article/0,3658,s=708&a=23115,00.asp
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Dr.math. W. Stürenburg
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB/GmbH, Consultant, Trainer
/_/ /_/\_, /___/\___\_\___/ Bielefeld, Germany
<___/ www.mysql.com +49-5744-5115-74 +49-172-938 0238


------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12880@lists.mysql.com
To unsubscribe, e-mail

Re: bug (feature?) wrt INSERT IGNORE & LAST_INSERT_ID

am 31.10.2002 14:26:02 von Benjamin Pflugmann

Hello Werver.

On Wed 2002-10-30 at 19:24:24 +0100, werner@mysql.com wrote:
[...]
> > This is one of the technical restrictions of using INSERT DELAYED and
> > documented accordingly:
>
> > http://www.mysql.com/doc/en/INSERT_DELAYED.html
>
> Sorry, I don't understand: we don't do any DELAYED stuff here.

Oops. I am very sorry. I misread IGNORE for DELAYED somehow.

> Also, the return value of the autoincrement value IS meaningful
> although there should be none. We talk about IGNORE here, which
> doesn't relate directly to DELAYED, if I am correct.

Correct.

> IGNORE should ignore the error here, but should it output the
> autoincrement value? It does not write the auto_increment value,
> though, so this is rather a cosmetical question. We better forget
> about it soon.

Just for completeness: The behaviour without IGNORE is the same. You
just get an error additionally.

> I understand the value has to be created before the insert, and
> when the insert fails, it is still there but isn't written, so
> the next insert will get this same value. It could be destroyed
> after the error occurs to keep picky people quiet...

Apparently this last step is not as easy as it sounds. I mean setting
it back to the previous value. If by destroying you mean simply
setting it to 0, I am not sure if that would not bring other problems,
but have to admit that I currently see no reason against it.

But a thought: If you want that LAST_INSERT_ID() is set to 0 on error
(or -1 or whatever), and want to handle that case, you effectively
want error handling for such INSERTs.

But OTOH with IGNORE you said that you are not interested in errors.
So, the other way around: If you are interested in a valid
LAST_INSERT_ID() you shouldn't use IGNORE. ;-)

You point stands, anyhow.


On Wed 2002-10-30 at 17:49:55 +0100, werner@mysql.com wrote:
> Hallo Benjamin!
>
> BLUSH!!! Poor me, embarrassed once more! Better take time to read
> the manual - well, this way I'll certainly learn!

Well, seems that I am the one that should take time to read.

Regards,

Benjamin.


--
benjamin-mysql@pflugmann.de

------------------------------------------------------------ ---------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)

To request this thread, e-mail bugs-thread12881@lists.mysql.com
To unsubscribe, e-mail