Remove identity retrieval statement for blob inserts (Sybase)

[perlpunk]

See https://gist.github.com/perlpunk/ab26c0d56f29bf29b747

When you have a table in Sybase with a text column, and you do an insert,
this will fail if you do it in a transaction because a
"SELECT MAX(id) ..." is appended to the SQL performing the blob insert.
Without a transaction a new $schema object is used which does not have
the _perform_autoinc_retrieval attribute set, so it suceeds

[perlpunk]

thought I might add the error message I got:

DBD::Sybase::st ct_data_info failed: OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (97)
Server servername, database
Message String: ct_data_info(GET): user api layer: external error: A CS_IODESC can only be retrieved
 for text or image columns.  Column 1 is not a text or image column.

ct_data_info(): text pointer is not set or is undefined. The text/image column may be uninitialized in the
 database for this row. [for Statement "SELECT content FROM mytable WHERE ( id = ? )
SELECT MAX(id) FROM mytable"] at DBIx-Class-0.082820/lib/DBIx/Class/Schema.pm line 1077.

[ribasushi]

Excellent stuff! Can you please add some extra code around https://github.com/dbsrgits/dbix-class/blob/v0.082820/t/746sybase.t#L336-L501, so that it fails before your patch and passes after?

The entire codepath is exceedingly gnarly, I really need to have a proper set of tests to guide me when the time comes to rewrite this from scratch.

Thanks!

[perlpunk]

yeah, you're right. Should have done that =)
I'm trying to reproduce it inside of the tests but somehow transaction_depth is 0 inside of the txn_do, so I first have to find out why the tests are behaving differently.

[perlpunk]

I added a test

[ribasushi]

This is finally vetted and applied as b8e92dac9. I apologize for the obnoxious delay, especially given that the final commit is exactly like yours (with an extra if() for a modicum of performance). I needed to make sure I looked through the entire stack before in fact knowing that this is the correct solution ( this also resulted in removal of a lot of superfluous logic: 216f29d9fe )

As far as your other problem - I could not figure out what set of events may cause it, and added a guard to make sure there is enough useful info when it is encountered again: 4a5fd481cb.

Both 4a5fd481c and b8e92dac will be lifted to https://github.com/dbsrgits/dbix-class/commits/maint/0.0828xx, with a trial expected in the next couple days, once I work out what happened in perlpunk@8a6afe5581

Stay tuned

[perlpunk]

Thanks!

[ribasushi]

The fix is now properly in the CPAN index. Sorry it took so long :/