Re: Problems with Hibernate Discriminators and 9.0-801.jdbc4

On Mon, Mar 28, 2011 at 3:13 PM, Oliver Jowett <oliver(at)opencloud(dot)com> wrote:

> On 29 March 2011 02:05, sdavidr <david(dot)ricoma(at)gmail(dot)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