[Koha-bugs] [Bug 10478] Do we need a sequential number generator?

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10478

M. de Rooy <m.de.rooy at rijksmuseum.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |http://bugs.koha-community.
                   |                            |org/bugzilla3/show_bug.cgi?
                   |                            |id=10454

--- Comment #4 from M. de Rooy <m.de.rooy at rijksmuseum.nl> ---
(In reply to comment #3)
> M. de Rooy, you use MySQL's LAST_INSERT_ID, which is not forward compatible
> with people who may be attempting to use a different back end, or working
> towards that.

See also more discussion about that on bug 9921. Note that it is still quite
hypothetical when Koha contains tens of mysql_insert_ids and other constructs
with specific date functions etc. But we should improve :)
The LAST_INSERT_ID construct prevents us from coding an exclusive row level
lock. The area of locking is also quite driver-sensitive. If I am correct, e.g.
PostgreSQL only blocks writing with such a lock and MySQL can block the read
with serializable isolation level, etc.
Whatever we do here, it looks like that we need some lines per db
implementation. If we add this for MySQL, everybody is welcome to add lines for
Pg, etc. (Not even talking about DBIx::Class yet :)

> The next problem is code that calls something to get the next number without
> actually having put it into a table anywhere and then calling it again when
> someone refreshed. Do we really want such gaping holes in the sequences we
> store?

You could assign the number only when you save the record. But still records
will be deleted. So there will always be gaps. The sequence number generator
could either not care about that, or also retrieve numbers from some kind of
buffer that is filled by a 'seqno garbage collector' (additional
functionality). Could you mention a case where this is considered important?

> Is the session id number, as stored in the CGISESSID cookie, unique enough,
> such that one could look for the session id to grab the sequence value to
> see if it is in the destination table, and if it is generate a new sequence
> number, otherwise reuse the one that is already pre-calculated?

Sounds like you want a random number instead now, why not just use a cpan
random number generator (several options) instead ?

Marcel

-- 
You are receiving this mail because:
You are watching all bug changes.