Hi,
> Do you think we should support the following?
>
> @DateInOrder
> void bookHotel(@NotNull @Valid Customer customer, Date from, Date to);
IMO that would be a useful feature. The following approaches came up
when discussing the idea earlier this year [1]:
1) A generic approach in the spirit o
No worries. Its 2 weeks till the next release window. Thanks for your
work on this and the others!
On Fri 08 Jul 2011 01:45:31 PM CDT, Scheper, Erik-Berndt wrote:
> Ok, thanks for looking into this, Steve. Actually I was already working on
> the 4.0 port and I'll definitely look into the Map s
I've created http://opensource.atlassian.com/projects/hibernate/browse/BVAL-232
On 8 juil. 2011, at 21:02, Kevin Pollet wrote:
> +1
> Good idea!!
>
> --Kevin
>
> Le 8 juil. 2011 à 16:03, Emmanuel Bernard a écrit :
>
>> Do you think we should support the following?
>>
>> @DateInOrder
>> void
+1
Good idea!!
--Kevin
Le 8 juil. 2011 à 16:03, Emmanuel Bernard a écrit :
> Do you think we should support the following?
>
> @DateInOrder
> void bookHotel(@NotNull @Valid Customer customer, Date from, Date to);
>
> ie like we have properly level and class level constraints, we could get
> me
FYI my reply
Hi guys,
This is a very good proposal and quite aligned with Bean Validation (BV) ideas
and with future plans we have for Bean Validation 1.1.
In particular, we plan to add method validations (somewhat close to how we have
designed it in Hibernate Validator (HV)
http://docs.jboss.o
Ok, thanks for looking into this, Steve. Actually I was already working on the
4.0 port and I'll definitely look into the Map sizing and take that into
account.
Unfortunately I won't have time to fix that this weekend, so I'll probably
submit updated / new pull requests for master and 3.6 eithe
Many thanks guys.
The good news is that we all are very much aligned in what we think. I am
writing an email to send this feedback to the JAX-RS team.
Emmanuel
On 1 juil. 2011, at 14:55, Hardy Ferentschik wrote:
> On Thu, 30 Jun 2011 22:04:39 +0200, Gunnar Morling
> wrote:
>
>> Some minor re
2011/7/8 Emmanuel Bernard :
>>
>> It's also nice to be able to verify compatibility of Search's use of
>> Lucene when using a backwards compatible index format.
>
> We don't have tests (today) that keep old index formats and run against the
> new version of HSearch. So the verification is an illus
On 30 juin 2011, at 18:25, Hardy Ferentschik wrote:
> I don't really understand though what the "Client API" really does, but maybe
> some
> syncing/brainstorming in the programmatic API area could be useful for BV and
> JAX-RS.
I agree, I think it would be better not to support such a model i
I think you should.
2011/7/8 Emmanuel Bernard
> BTW I forgot but do we support Constructor validation?
>
> On 8 juil. 2011, at 16:02, Emmanuel Bernard wrote:
>
> > Do you think we should support the following?
> >
> > @DateInOrder
> > void bookHotel(@NotNull @Valid Customer customer, Date from,
BTW I forgot but do we support Constructor validation?
On 8 juil. 2011, at 16:02, Emmanuel Bernard wrote:
> Do you think we should support the following?
>
> @DateInOrder
> void bookHotel(@NotNull @Valid Customer customer, Date from, Date to);
>
> ie like we have properly level and class level
>
> It's also nice to be able to verify compatibility of Search's use of
> Lucene when using a backwards compatible index format.
We don't have tests (today) that keep old index formats and run against the new
version of HSearch. So the verification is an illusion :)
>
> I think we're not trac
So the testsuite is using an helper method
"org.hibernate.search.test.SearchTestCase.getTargetLuceneVersion()"
for all those cases in which the unfriendly Lucene API demands a version.
The test method is currently returning this constant:
Version.LUCENE_31
The ConfigContext is using a default of
Looks good. I added a few minor comments. I'd like to see the Map
sizing thing addressed and the 4.0 port done, but I have no problems
with these changes.
On Fri 08 Jul 2011 07:32:25 AM CDT, Adam Warski wrote:
> As Eric wrote this fix is needed to fix an Envers issue (HHH-6349), however I
> d
Good idea.
On Fri, 08 Jul 2011 16:02:03 +0200, Emmanuel Bernard
wrote:
> Do you think we should support the following?
>
> @DateInOrder
> void bookHotel(@NotNull @Valid Customer customer, Date from, Date to);
>
> ie like we have properly level and class level constraints, we could get
> met
Cool Stuff !! +1
2011/7/8 Emmanuel Bernard
> Do you think we should support the following?
>
> @DateInOrder
> void bookHotel(@NotNull @Valid Customer customer, Date from, Date to);
>
> ie like we have properly level and class level constraints, we could get
> method level constraints receiving a
Do you think we should support the following?
@DateInOrder
void bookHotel(@NotNull @Valid Customer customer, Date from, Date to);
ie like we have properly level and class level constraints, we could get method
level constraints receiving all the parameters and raising constraints
violations if
As Eric wrote this fix is needed to fix an Envers issue (HHH-6349), however I
don't feel competent to review the patch for hibernate-core.
So maybe someone else could try? :)
Thanks,
Adam
On Jul 4, 2011, at 3:20 PM, Scheper, Erik-Berndt wrote:
> Hi,
> I'd like someone to review my proposed fix
On 08.07.2011, at 14:02, Emmanuel Bernard wrote:
>
>> So this boils down whether a final method can be intercepted or not. But
>> isn't Javassist capable of doing so?
>
> I imagine you can intercept a final method via bytecode enhancement but we do
> proxy generation, not bytecode enhancement
> So this boils down whether a final method can be intercepted or not. But
> isn't Javassist capable of doing so?
I imagine you can intercept a final method via bytecode enhancement but we do
proxy generation, not bytecode enhancement for many reasons.
(we do have a bytecode enhancement mode bu
Many thanks for your answers! To sum this up:
Final methods don't prevent Hibernate from creating a proxy in general but
unless those methods
don't use any state of the entity this is highly inadvisable.
Since I have several methods in base classes which indeed don't use any entity
state this i
On 8 juil. 2011, at 11:44, Robin Sander wrote:
>
> Isn't that totally independent from a method beeing final or not?
> If I have a method:
>
> public int getSum() {
> return field1 + field2;
> }
>
> Then this would trigger the initialization of the entity (in
> JavassistLazyInitializer I ass
Isn't that totally independent from a method beeing final or not?
If I have a method:
public int getSum() {
return field1 + field2;
}
Then this would trigger the initialization of the entity (in
JavassistLazyInitializer I assume)
and
public final int getSum() {
return field1 + field2;
}
If your toString method ends up calling some of the entity state (likely), the
initialization won't be triggered since you will call your getters from inside
the instance. So it's a good general rule to mandate non final methods on
entities.
Emmanuel
On 8 juil. 2011, at 09:59, Robin Sander wro
Hi all,
excuse me if this list isn't indented for such a question, but I asked this
question about a year ago in the forums
without any answers and I think it should be easy to answer for any Hibernate
core developer:
According to Hibernate's (3.6.5) reference documentaion (Section 21.1.3,
Si
25 matches
Mail list logo
