I guess the suffix solution is not harmful and we can always expose the more
elaborate solution if needed later.
On 11 janv. 2010, at 17:23, Steve Ebersole wrote:
> I need to add a way to further define the type of numeric literals.
> Currently HQL supports the use of the 'F', 'D' and 'L' suffix
Nice, done: depending on Lucene 2.9.1 right now.
Sanne
2010/1/11 Emmanuel Bernard :
> Right, go forward and temporarily break COMPRESS.
> Option B (ie use CompressionTools) seems like a better option than getting
> rid of it altogether.
> I think we should offer a pluggable compression method bu
Right, go forward and temporarily break COMPRESS.
Option B (ie use CompressionTools) seems like a better option than getting rid
of it altogether.
I think we should offer a pluggable compression method but I would not mind it
being global and thus not require change to the enum.
On 11 janv. 2010
I forgot about this behavior, I thought you were raising an exception during
the sync mode (even if run with parallel processes). That definitely looks like
the right thing to do.
So an exception strategy should:
- know if it's a synchronized call or not
- know the list of operations that are
I need to add a way to further define the type of numeric literals.
Currently HQL supports the use of the 'F', 'D' and 'L' suffixes as
defined by Java to demarcate floats, doubles and longs respectively. I
find myself the need to do the same with BigInteger and BigDecimal.
I see two options:
1
