Skip Menu |
 

This queue is for tickets about the SQL-Bibliosoph CPAN distribution.

Report information
The Basics
Id: 77216
Status: open
Priority: 0/
Queue: SQL-Bibliosoph

People
Owner: Nobody in particular
Requestors: JKRAMER [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 2.45
Fixed in: (no value)



Download (untitled) / with headers
text/plain 207b
INSERTs don't return the last_insert_id for PostgreSQL (or probably anything else but MySQL). Looks like the value is hardcoded to a MySQL-specific key, when it should use DBI->last_insert_id to be portable.
Download (untitled) / with headers
text/plain 290b
On Tue May 15 07:26:42 2012, jkramer wrote: Show quoted text
> INSERTs don't return the last_insert_id for PostgreSQL (or probably > anything else but MySQL). Looks like the value is hardcoded to a > MySQL-specific key, when it should use DBI->last_insert_id to be portable.
Thanks. I will fixit this week.
Download (untitled) / with headers
text/plain 792b
Since DBI's last_insert_id has very different behaviors depending the driver, I add this to the documentation: Note that $last_insert_id is only returned when using MYSQL (undef in other case). When using other engine you need to call an other query to get the last value. For example, in ProgreSQL you can define: --[ LAST_VAL ] SELECT lastval() and then call LAST_VAL after an insert. ok? thanks. On Tue May 15 13:12:03 2012, MATIU wrote: Show quoted text
> On Tue May 15 07:26:42 2012, jkramer wrote:
> > INSERTs don't return the last_insert_id for PostgreSQL (or probably > > anything else but MySQL). Looks like the value is hardcoded to a > > MySQL-specific key, when it should use DBI->last_insert_id to be portable.
> > Thanks. I will fixit this week.
Download (untitled) / with headers
text/plain 1.2k
Instead of always returning undef, it would be helpful to return a value that at least indicates whether the INSERT succeeded or not. Even better would be to somehow make the value configurable for the user, maybe using an anonymous function, so I could for example override the default behavior by giving 'insert_return => sub { return $_[0]->dbh->last_insert_id }' or something like that to the constructor. On Tue May 15 14:20:27 2012, MATIU wrote: Show quoted text
> Since DBI's last_insert_id has very different behaviors depending the > driver, I add this to the > documentation: > > Note that $last_insert_id is only returned when using MYSQL (undef > in other case). > When using other engine you need to call an other query to get the > last value. > For example, in ProgreSQL you can define: > > --[ LAST_VAL ] > SELECT lastval() > > and then call LAST_VAL after an insert. > > ok? > > thanks. > > > On Tue May 15 13:12:03 2012, MATIU wrote:
> > On Tue May 15 07:26:42 2012, jkramer wrote:
> > > INSERTs don't return the last_insert_id for PostgreSQL (or
> probably
> > > anything else but MySQL). Looks like the value is hardcoded to a > > > MySQL-specific key, when it should use DBI->last_insert_id to be
> portable.
> > > > Thanks. I will fixit this week.
>
On Wed May 16 06:43:12 2012, jkramer wrote: Show quoted text
> Instead of always returning undef, it would be helpful to return a value > that at least indicates whether the INSERT succeeded or not. Even better > would be to somehow make the value configurable for the user, maybe > using an anonymous function, so I could for example override the default > behavior by giving 'insert_return => sub { return > $_[0]->dbh->last_insert_id }' or something like that to the constructor.
thanks again! It actually returns 'undef' in case of success ( $stm->rows() != 0), and 0 in case of error (I know...). The customizable return value sounds ok. The insert_return function will receive the statement return, and the default insert_return will be: // sub insert_return { my ($selt, $statement) = @_; return 0 if ($statement->rows() || 0) == -1; return wantarray ? ($statement->{mysql_insertid}, $statement->rows() ) : $statement->{mysql_insertid} ; } // Does it make sense to you?


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.