[HSEARCH] @DateBridge and @Field(index=Index.UN_TOKENIZED)
by Emmanuel Bernard
Does it ever make sense to use @DateBridge without @Field(index=Index.UN_TOKENIZED) or NO_NORM
I got caught up with doing
@DateBridge(resolution=DAY) @Field
public String getDate() { return date; }
and having unexpected issues.
If it never makes sense we could raise an exception when that happens, or simply force the index strategy to UN_TOKENIZE.
WDYT?
15 years, 10 months
IRC meeting
by Steve Ebersole
This week we discussed progress on 3.6:
1) both of the main features (types and key-many-to-one) are largely
done; so I will start making the pre-release schedule for alphas/betas
2) discussed merging of annotations again; basically holding until the
docs are merged.
3) discussed possibility of merging jmx code back into core as well now
that we have moved to JDK 1.5 which includes the jmx classes
4) discussed possibility of merging testing/testsuite back into core as
well. revisited why, maven limitations, and discussed move to gradle as
a way to alleviate this as well as other issue we have with maven.
5) As a follow up to the gradle discussion we agreed to not decode
today. We will put this off until next week. But if importing a gradle
project into both eclipse and intellij is working and we can get the
jdocbook stuff working in gradle, then i plan on moving to gradle for
the build.
6) move to H2 as default test database complete on trunk. This led to a
general realization that we may need to revamp our temp table usage a
bit on a few databases. I will send a follow up email about that topic
a little later.
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
15 years, 10 months
HV-274 - Write a programmatic mapping API for constraint declarations
by Hardy Ferentschik
On Thu, 20 May 2010 23:49:00 +0200, Gunnar Morling
<gunnar.morling(a)googlemail.com> wrote:
> personally I feel that the proposed definition classes bring quite a
> large (conceptual and technical) overhead to the table. Writing them
> from hand
> isn't really cool, building an AP for this OTOH seems a lot of work for
> this feature which I think might have not that much users.
True, this feature might not have too many users, but we have to see the
overhead from
a user's perspective and not from ours.
The effort to implement the current solution lies somewhere between the
fully types
version
(config.type(ShoppingCart.class).getter("items").size().max(30).notNull())
and the completely "untyped" one. As a bonus the required definition
classes could
be generated via an annotation processor. Given what we have learned so
far with
annotation processors it should not be too hard to write one.
By introducing a package org.hibernate.validator.cfg and the
ConstraintMapping class the conceptual overhead is isolated and the
integration into the core validator framework was not too
hard. Not much different than adding xml configured constraints.
> What do you think about the proposal I added as comment to the JIRA
> issue?
> It allows to reference each constraint's attributes in a safe manner
> without the need for additional definition classes.
True, we don't have to create any new classes within the framework, but to
use the
API you have to create constraint instances which makes the API not really
fluent
in the same way as the other APIs we recently introduced.
That said, I am not the big fluent API proponent. There are other team
members who
stand for that ;-)
> The thing is actually I'm not sure, what use cases this API will have. I
> doubt someone would really use it by hand (as annotations are much
> simpler).
I see the biggest usecase in testing, but as you mention code generation
is an option as
well.
> Slightly OT, but what I really *would* like is an AP/some other tool for
> generating property definitions for arbitrary POJ(O|I)s ("property
> literals"). Allowing bean properties to be accessed in a safe way seems
> useful in many scenarios (besides the use case here, for data binding in
> GUIs for instance). I'm thinking about to build such a tool, if I only
> had more time for these things :-)
I see the use cases as well, but this is not the job of an annotation
processor, since
you want to create meta class for all pojos (independent of annotations).
Sounds more like
a build (maven) plugin.
Personally I am still not sure if we take this whole type-safety thing not
too far.
--Hardy
>
> 2010/5/20 Hardy Ferentschik <hibernate(a)ferentschik.de>
>
>> Hi,
>>
>> The approach is looking somewhat like this:
>>
>>
>> config
>> .type(ShoppingCart.class)
>> .getter("items")
>> .constraint(NotNullDefinition.class)
>> .constraint(SizeDefinition.class)
>> .min(3).max(10);
>> .getter("price")
>> .constraint(RangeDefinition.class)
>> .min(0)
>> .max(100)
>>
>>
>> Instead of getter it will be property. Here is a running example:
>>
>>
>> ConstraintMapping mapping = new ConstraintMapping();
>> mapping.type( Marathon.class )
>> .property( "name", METHOD )
>> .constraint( NotNullDefinition.class )
>> .property( "numberOfRunners", FIELD )
>> .constraint( MinDefinition.class
>> ).value( 1
>> );
>>
>>
>> Check the classes in org.hibernate.validator.cfg. I checked in some
>> initial
>> work.
>> Not everything is wired up though. Feel free to send me some feedback.
>> Work is still in progress. One idea I had is to generate the
>> XYZDefinition
>> classes via
>> an annotation processor ;-) Not sure if this is happening now or if I in
>> the first cut just
>> add the definition classes for the builtin constraints.
>>
>> --Hardy
15 years, 11 months
org.hibernate.test.annotations.beanvalidation.DDLWithoutCallbackTest
by Steve Ebersole
In trying to switch over to h2,
org.hibernate.test.annotations.beanvalidation.DDLWithoutCallbackTest is
failing when run against h2 whereas it passes with hsqldb.
The difference is that when run against hsqldb no check constraint is
defined when the table is created. But the check constraint is defined
when the table is created on h2.
The test does say :
cfg.setProperty( "javax.persistence.validation.mode", "ddl" );
Isn't the point of this to generate the check constraints in the
database? Basically isn't this test just defined to pass on hsqldb and
fall on others?
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
15 years, 11 months
banner links broken on forum
by Sanne Grinovero
Hello,
please take note that the links to both books on the forum are broken
ass they redirect to the new wiki:
"Sorry, the page you're looking for cannot be found."
Cheers,
Sanne
15 years, 11 months
cant build trunk
by Strong Liu
Running org.hibernate.dialect.resolver.DialectResolverTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Results :
Tests in error:
testHiLoAlgorithm(org.hibernate.id.SequenceHiLoGeneratorTest)
Tests run: 106, Failures: 0, Errors: 1, Skipped: 0
-----------
H2 driver is used in this test, but the H2 profile is not actived by default.
-------------------------
Best Regards,
Strong Liu <stliu at redhat.com>
15 years, 11 months
resolve/log test failures on other DBs instead of the default (h2/hsqldb)
by Strong Liu
Hi all,
as we have setup the hudson job for Core trunk and branch 35, although there are some problems with our code (lock in db2/postgresql, test fails on h2 for trunk).
I'd suggest once those resolved, please watch the test result after you commit something, not only the default db job, but all DB matrix test result.
if the commit causes test fails on other db, please resolve it or mark it as failure expect and open a jira.
Hardy, i'm think @FeatureExpect needs a new property something like
@FeatureExpect(jiraKey="HHH-5555", message="mssql, sybase, db2 do not support xxx", applyTo={SqlServerDialect.class, SybaseASE15Dialect.class, DB2Dialect.class}
we can talk this in next week dev meeting, anyway, it will be great if we get all balls blue :D
-------------------------
Best Regards,
Strong Liu <stliu at redhat.com>
15 years, 11 months
Problems deploying 3.5.2-Final
by Gail Badner
When I executed "mvn deploy", I got:
[WARNING] Entry:
hibernate-distribution-3.5.2-Final/project/cache-ehcache/src/test/java/org/hibernate/cache/EhCacheTest.java
longer than 100 characters.
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Failed to create assembly: Error creating assembly archive dist:
Problem creating TAR: request to write '8192' bytes exceeds size in
header of '3276746' bytes
I'm calling it a night.
Cheers,
Gail
15 years, 11 months
