Hi,
A small FYI crosspost here since both communities has talked about it.
Tonight I tried out Derby and followed the advise about running Derby
with the JVM wide system property derby.system.durability to the value
test.
It certainly has an effect, but Derby is still sluggish with this sett
the user forum would be more correct.
but a small tip is that jira and documentation contains notes
on the fact that you need to list all parts of the composite id to
make it work.
/max
So I sent an email to this list yesterday about an issue I encountered
where I get malformed SQL when I
hhh-702 is done now. native sql have never been easier ;)
/max
im messing around with HHH-702, but it ain't critical for rc2.
/max
So as far as I am concerned, I am ready to push out 3.1rc2. Anything
anyone else wanted to get into this before I cut it?
I hope to get time to do it this wee
So I sent an email to this list yesterday about an issue I encountered
where I get malformed SQL when I make an HQL createQuery() call
containing an "order by" clause which refers to a composite ID. I
haven't gotten any responses to that email, but I've dived into the
Hibernate source and am
im messing around with HHH-702, but it ain't critical for rc2.
/max
So as far as I am concerned, I am ready to push out 3.1rc2. Anything
anyone else wanted to get into this before I cut it?
I hope to get time to do it this weekend. If not, it'll be early next
week.
Here is the change-log
So as far as I am concerned, I am ready to push out 3.1rc2. Anything
anyone else wanted to get into this before I cut it?
I hope to get time to do it this weekend. If not, it'll be early next
week.
Here is the change-log so far:
** Bug
* [HHH-1045] - Example contains inner classes that ar
At least in part because of EJB3 support, the Hibernate queries need to
add the ability to better "guess" a parameter's type. The way this is
being done is to base the "expected type" off the type of the property
to which the parameter is related; previously, this just performed a
guess based on t
