Re: [hibernate-dev] [Bean Validation] @Max / @Min as double instead of long
Using the String value could be a good idea also for double,
not very clean but safe.
2009/3/5 Emmanuel Bernard :
> I mean we could but we would need to rely on the string representation
>
> @interface Max {
> String value()
> }
>
> @Max("12.5")
> double someNumber;
>
>
> On Mar 4, 2009, at 19:17, Emmanuel Bernard wrote:
>
>> Unfortunately, you can't support Big* as they are not expressible in
>> annotations
>>
>> @interface Max {
>> BigDecimal value();
>> }
>>
>> does not compile.
>>
>> On Mar 4, 2009, at 19:14, Elias Ross wrote:
>>
>>> On Wed, Mar 4, 2009 at 3:49 PM, Emmanuel Bernard
>>> wrote:
[Follow up with Sebastian]
Well good point and frankly I do not know :)
1. do we support float and double for @Min / @Max?
2. if 1 is yes, I'd be inclined to say the value should be double but
that's
not fully automatic.
>>>
>>> How would you go about supporting @Max / @Min for java.math.BigDecimal
>>> ? These would be more useful, since think a lot of this sort of
>>> validation is intended to fulfill business rules and business math
>>> requires exact (not floating point) math.
>>>
>>> And even in situations you use floating point math, the input and
>>> state should be probably a BigDecimal value but internally
>>> calculations could be done (for sake of expedience) using a double
>>> conversion.
>>>
>>> I would probably create a separate @MaxDouble and @MinDouble
>>> annotation, if at all, but I wouldn't feel easy suggesting users build
>>> constraints using floating point comparisons.
>>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Bean Validation] @Max / @Min as double instead of long
On Wed, Mar 4, 2009 at 4:20 PM, Emmanuel Bernard wrote:
> I mean we could but we would need to rely on the string representation
>
> @interface Max {
> String value()
> }
>
> @Max("12.5")
> double someNumber;
There's very few domains where you want to be validating user input
and storing it as a double. For reasons you talked about and also just
for returning back what the user typed in a form, for instance,
doubles aren't user friendly. Thus, I don't see why validating a
double should be necessarily supported. Most developers people don't
understand floating point very well, and your average user is unlikely
to know about rounding errors and inexact representation, etc.
In my original question, I was considering validation cases when you
are using a BigDecimal. The common use case is validating a column
from a database. Databases columns most often use exact
representations of decimal numbers, for obvious reasons when working
with money. There, you don't want to be storing data in doubles! In
any case, I would assume you'd want to indicate something similar to:
@Max("12.5")
BigDecimal someNumber;
Since the BigDecimal and BigInteger have String constructors that are
well defined, a String representation seems fine.
There's other restrictions you may want to make as well. For instance,
you may want to restrict values to at most N decimal places or
significant digits, i.e. precision. This is useful in scientific
applications. How might you represent that?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Bean Validation] @Max / @Min as double instead of long
On Thu, 05 Mar 2009 10:30:49 +0100, Elias Ross
wrote:
@Max("12.5")
BigDecimal someNumber;
Since the BigDecimal and BigInteger have String constructors that are
well defined, a String representation seems fine.
The string representation is probably less intuative though, especially
for int/Integer/long/Long. And of
course it is prone typos.
There's other restrictions you may want to make as well. For instance,
you may want to restrict values to at most N decimal places or
significant digits, i.e. precision. This is useful in scientific
applications. How might you represent that?
Is this not covererd by @Digits?
--Hardy
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] HHH-3225 is hitting Hibernate Search
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3225 Steve, any chance you could look at this one, it seems to hit HSearch users on a regular basis. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Search road map
Sorry for the delay Sanne and thanks for the constant work. Feel free to bug me I will say no if I can't. On Feb 25, 2009, at 06:19, Sanne Grinovero wrote: Hi, I am happy with the "new features" in the roadmap, but still a bit worried about some open issues: HSEARCH-314 is quite annoying and I've run out of ideas to propose; any direction from someone? I added some notes in JIRA. Feel free to tell me if you update this jira (I might miss it). It would be nice if the solution could be reused also by other listeners (a topic for JPA2 spec?) forget it. HSEARCH-178 is very annoying and I see it hitting many people; probably the new HSEARCH-342 is another duplicate. what makes you think it's a duplicate? ** About mass indexing ** I've lots of implementations in house, mostly experiments, many working well, but I can't really satisfy all requirements. Could we define exactly which requirements the first public version should be able to cover? In particular: * if it should work on any backend (using the pluggable backend api) or generate a local file index, reusing some backend code but using a direct reference instead of going through the interface and skipping the "Work" value objects. ping me tomorrow or this week end, or detail that point, I don't understand what you are proposing. Yes it should work on any backend. * Composite pk: to have a consistent view of DB even in multithreaded indexing on an online DB the best solution I've found is to have a single-threaded pk producer (load all pk's from db) which hands the pks to multiple object loaders, and at the same time keep track of other enqueued events (to process them in order at the end of indexing). This works ok if the pks are simple value objects, not graphs of composite objects ;-) Is it because it's "hard to do" or is a conceptual problem. I am happy to not support that for the first release. * The API: my first ideas were about defining the indexing finetuning parameters (loading queries, caching, number of threads, queue sizes...) on an annotation on top of the class. Emmanuel didn't like it, and I don't like it either anymore: still some API should be defined; to be flexible enough I was thinking in something like this: SearchIndexer si = (SearchFactory instance).createIndexer(); // to rebuild all indexes, or sf.createIndexer( Class... types) si.setIndexWritingThreads( 2 ); // optional, default to 1 si.setLoadingThreads( 8 ); // optional, default to 1 si.setCacheMode( CacheMode... ); // optional, default to IGNORE in some acses useful to not ignore. si.setOptimizeAtEnd( false ) // optional, default to true si.setPurgeAllAtStart( false ) // optional, default to true (does purge and optimize) si. --add more options in future as needed -- si.start(); // can call it only once si.waitForFinish( timeout ) // optional looks good but try and make it a fluent API (ie method chaining returning si and remove set in set*. Is there any non optional setter? Additionally, I would like to add some way that the user could define an optimal loading query, but this gets messy to check, especially in cases I am indexing different types having some inheritance relationship. We could leave this for future, or only add something like a Criteria.setFetchMode scoped per type, which is what I ususally need: si.setFetchMode(Class scopeHintToType, String relationName, FetchMode). Couldn't you use the same thing that we did for FullTextQuery with setCriteria? I am happy to delay that for later. Especially since JPA2 is coming with a criteria API. The time to implement really depends on the amount of integration desired with the current backends; as to make a trivial local indexer I've lots of code to paste as soon as the API is set. I've some optimizations for the future, but would like to provide at least the basics soon. regards, Sanne 2009/2/20 Emmanuel Bernard : I updated the road map http://www.hibernate.org/357.html#A12 Mass indexing Dictionary / spellchecker support Work on easier query building More like this? Built-in clustering with JBoss cache Statistics custom LockFactory feel free to propose other new features. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Search road map
On Feb 25, 2009, at 06:19, Sanne Grinovero wrote: HSEARCH-314 is quite annoying and I've run out of ideas to propose; any direction from someone? It would be nice if the solution could be reused also by other listeners (a topic for JPA2 spec?) See my other email on the Core issue. It's not entirely in my hands, more on Steve's ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HHH-3225 is hitting Hibernate Search
Is this somehow different than the "attempt to load stuff into the PC during flush" scenarios I see in any of these related issues? - Steve Ebersole Project Lead http://hibernate.org st...@hibernate.org Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com steve.ebers...@jboss.com steve.ebers...@redhat.com On Thu, 2009-03-05 at 19:14 -0500, Emmanuel Bernard wrote: > http://opensource.atlassian.com/projects/hibernate/browse/HHH-3225 > > Steve, any chance you could look at this one, it seems to hit HSearch > users on a regular basis. > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
