If the queries which put NULL into AUTOINCREMENT NOT NULL columns are
changed to insert a zero instead, then MSSQL can use its IDENTITY(1,1)
without requiring nextSequenceValue().
Simetrical wrote:
On Mon, May 12, 2008 at 12:33 PM, Brion Vibber
<brion(a)wikimedia.org> wrote:
Rather than making assumptions about field names
(which sounds like
baaaad mojo that can break in many exciting ways), it may be more
reliable to use a special value here.
Using a type-safe value (say, returning an object of a particular class
from nextSequenceValue()) could allow the database class to drop the
column from the query in a safe way.
Yeah, River pointed this out to me on IRC, I was going to say.
Defining class MSSQLAutoincrement {} and then returning that with
DatabaseMSSQL::nextSequenceValue() and checking for it in the insert
logic (and dropping that part of the insert) would be the way to go
here.
How does
PostgreSQL handle this? If you know what type the column is,
you can cast it in the application logic. Again, it would seem better
to implement this checking in the cross-database code and raise
warnings if it comes up so it can be fixed on a case-by-case basis.
This doesn't work with MySQL strict mode either, which is the default
under some circumstances last I heard.
This is simply a case where if it's going on, it's a bug in the code.
Don't "work around" it in the database class, just fix it! :)
Yup.
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l