Hello,
I'm wondering how you'd all feel about the third solution:
3. don't do it.
This depends of course how far it is blocking in practice. Maybe I'm
missing something, but couldn't a user simply use an additional
@AnalyzerDef, so that the analyzer definition is associated to a name,
and use t
> I'm wondering how you'd all feel about the third solution:
> 3. don't do it.
> This depends of course how far it is blocking in practice.
"Don't do it until 6.0" would be acceptable, I guess, since it's still just
a technical preview. Though we would introduce a limitation that would only
be our
On 5 January 2017 at 13:06, Yoann Rodiere wrote:
>> I'm wondering how you'd all feel about the third solution:
>> 3. don't do it.
>> This depends of course how far it is blocking in practice.
>
> "Don't do it until 6.0" would be acceptable, I guess, since it's still just
> a technical preview. Tho
> I don't disagree, I'm merely aiming to have in future Analyzer(s)
> defined in a non-Lucene specific way, possibly allowing controlled
> exceptions.
> When changing the definitions API we'll be able to reconsider if we
> want Analyzer definitions to be scoped per index like Elasticsearch
> does.
Hello everybody, holidays are over and we decided to start back with a
small release.
Hibernate OGM 5.1 Beta3 and a new 5.0 maintainance releases are now available.
In these releases we fixed some issues around sequence generation and
queries on entities using the single table per class inheritan
For future reference,
these problems should be fixed now.
If a job build does not trigger from a PR and everything seems right,
check the advance configuration option under:
Build Triggers > GitHub Pull Request Builder > Trigger phrase
If it's blank try set it to something like: .*test\W+this\W+
> If a job build does not trigger from a PR and everything seems right,
> check the advance configuration option under:
I meant, if a build does not start when you leave the comment:
"Jenkins, rebuild this please"
On Thu, Jan 5, 2017 at 4:04 PM, Davide D'Alto wrote:
> For future reference,
> the
Hi,
That's a catchy subject, now I'm sure I got Guillaume's (angry) attention :)
Sanne wanted us to think about feature removal... Here's a proposal.
The feature I'd like to deprecate/remove: automatic truncation of
date/calendars to a given resolution. It's used like that:
@Field
@CalendarBrid
