All right, I certainly don 't want to change anything to the initial
filtering capability, because there are already usecases as is. What I
was thinking of was an optional enhancement. The more I think on this
one, the more I think events are more appropriate when dealing with
security (the JAC
"Late" detection of scalar types in native SQL when type is not
explicited for this column. Needed to complete the EJB3 support.
Gavin King wrote:
I’ve put some thought into the scope of work for Hibernate 3.1.
Here’s what I came up with:
* Finish bulk update/delete, including, HHH-352
On Thu, 09 Jun 2005 11:28:46 +0200, Emmanuel Bernard
<[EMAIL PROTECTED]> wrote:
"Late" detection of scalar types in native SQL when type is not
explicited for this column. Needed to complete the EJB3 support.
Did we not conclude that this was not the case in EJB3 ?
I don't see this in the
Hello,
- update/insert/delete in ScrollableResults in same session - it would be nice
for swing long session
Thanks
On Wednesday 08 June 2005 07:19 pm, Gavin King wrote:
> As you all know, I am still just not sold on this.
>
> -Original Message-
> From: Max Andersen
> Sent: Wednesday, 8
No, this is the case. This part is not very explicit, but the intention
is there. The type declaration will not be provided by the spec.
Max Rydahl Andersen wrote:
On Thu, 09 Jun 2005 11:28:46 +0200, Emmanuel Bernard
<[EMAIL PROTECTED]> wrote:
"Late" detection of scalar types in native SQL
On Thu, 09 Jun 2005 14:13:27 +0200, Emmanuel Bernard
<[EMAIL PROTECTED]> wrote:
No, this is the case. This part is not very explicit, but the intention
is there. The type declaration will not be provided by the spec.
thats stupid. No way at all of specifying the type ?
I know that's its a
Hello,
First of all I'm sending this patch that resolves the problem of the
missing primary key on associations tables for many to many relations (I
set the pk to the concatenations of joinColumns+inverseJoinColumns).
Second I have a doubt with the changes in the events classes. I'm
using
Hi Pablo,
Did yhou open a JIRA issue for this one, I can't find it. I remember I
was alerted to this problem but I can't remember where ;-)
While looking at your patch, I just realized that this was the expected
behavior. Let me explain.
by default @JoinColumn(nullable=true) which means that FK
