On Mon, Mar 28, 2011 at 3:13 PM, Oliver Jowett
<oliver@opencloud.com> wrote:
As Dave said, unless you explicitly ask for certain columns, it gives
you the entire inserted row because trying to determine a smaller set
of "generated" columns requires information that the driver doesn't
have. It's fine from a spec point of view to do this. Also, even if we
could find a smaller set of columns to return, there still might be
more than one and Hibernate would still fail ..
Yes, most definitely. In my case, I've got an mtime and btime column declared in a super table but the id column itself is declared in the subtable. mtime is generated by a trigger on insert/update, so even if the driver returned only the columns that are generated, it would still return mtime and my id column, and mtime will always be first, since it comes from the super-table. The mtime column is marked in the hibernate mapping as a generated column, so hibernate should be capable of dealing with at least 2 columns coming back from the query and there is no question that assuming a particular column order is a bug, plain and simple. The bug is 100% in hibernate. I don't know my way around hibernate's internals, but I spend a very long evening attempting to figure out how to modify the code such that I could get the name of the id column from the mapping, but the way the code was structured, I couldn't do so without changing a long chain of method signatures. I gave it up for a lost cause and changed to an explicit sequence id generator instead of the 'identity' id generator which is supposed to use a db-specific auto-increment mechanism. You can do that without changing any schema at all, since it only requires knowing the name of the sequence being used by postgres, which is easy enough to determine.
--sam