On Sat, 25 Apr 2009, Jeppe Sommer wrote:
> So what you are saying is that ResultSetMetaData.isAutoIncrement will only
> return true for a subset of the fields that are actually autogenerated? But
> perhaps it could serve as a starting point.. The jdbc apidoc is not very
> precise on what constitutes an autogenerated key, maybe
> autogenerated=autoincrement is even a valid interpretation?
Yeah, it doesn't really say anything about what autogeneratedkeys are. I
would take auto-generated to mean, "any field that gets a value that
wasn't directly provided." That would include defaults and things set by
triggers. I would take key to mean "any field that's part of an index."
But putting these together doesn't seem to make a whole lot of sense.
Would you not return a value generated by a serial column just because it
didn't have an index on it? Given that it's poorly defined and because I
wanted to avoid having to parse the provided query, what's been done is to
just return everything possible and let the caller deal with it. If the
data isn't there, the caller can't do anything about it. If there's too
much, the caller can just ignore it.
> I'm not trying to improve performance, only to get the correct behaviour. I
> introduced the filtering because the application (actually the Spring
> framework) failed on receiving all fields when it was expecting only the
> generated field(s).
>
Failed how (a stacktrace for example), perhaps it would be better to fix
Spring?
Also, I thought of an issue with your patch. It will only work when using
the V3 protocol. When connected to a server via V2, we don't get the base
table information, ResultSetMetaData.isAutoIncrement will always return
false.
Kris Jurka
