Hey,
I wanted to know if it is possible to give two conditions on two different
fields in one filter? eg. isDeleted='false' and sversion=3. if yes then how?
Also can we apply two filters to a session? if yes how?
Thanks
Ankita
___
hibernate-dev mailing l
I've tracked and hunted down a small but impacting bug for Hibernate OGM.
https://hibernate.onjira.com/browse/HHH-6724
I am not sure about the CR status but if you could squeeze this one in, I would
be grateful. I have committed it in upstream master and all tests pass.
BTW this bug was also pre
I can work on some of the test failures today. Which dialect should I look at?
Regards,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
On 11 October 2011 17:00, Emmanuel Bernard wrote:
> I see where you're coming from.
> There are two options:
> - don't care that much
> - rename default to default_for_index or index_default (or some long and
> annoying name like that) and deprecate default
I'm tempted for option 1) "don't care
I see where you're coming from.
There are two options:
- don't care that much
- rename default to default_for_index or index_default (or some long and
annoying name like that) and deprecate default
Do you really think filter is in as much need as index for a default? Any other
category that woul
[10:33] Meeting ended Tue Oct 11 15:33:13 2011 UTC. Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
[10:33] Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2011/hibernate-dev.2011-10-11-15.09.html
[10:33] Minutes (text):
http://transcripts
>
> I am against it. All the doc is consistent, I don't want two options to do
> one thing if they are strictly equivalent.
Sure, I'm not suggesting to support it: as I've written in the
description of HSEARCH-942 such a property should log a warning: we
could warn only, but we could also warn an
On 11 oct. 2011, at 16:52, Sanne Grinovero wrote:
>>> We have an issue open around reviewing configuration properties, this
>>> thought was one of the reason to open it:
>>>
>>> HSEARCH-859 - Review names and composition of configuration properties
>>
>> I know. I mentioned it to Emmanuel today
On 11 oct. 2011, at 16:43, Hardy Ferentschik wrote:
>>
>> on b) : I really think this ".default" business got out of hand; it
>> made sense in initial days as there wasn't much to configure, but
>> nowaday? Is it still self-speaking that "default" relates to the
>> IndexManager / indexes
>
> No
I generally agree with the direction described by Hardy.
Some comments inline
>> * the index manager gives access to directory and reader provider as well
>> as the backend to be used
>
> This is a tricky point. Generally this is correct, especially for the
> default IndexManager, but alternative
>> Didn't we have the discussion once before? We do it this way, because
>> its
>> what we do in Core? But I think even there we have some
>> org.hibernate.xyz
>> and some hibernate.xyz
>>
>> I have no strong opinion on transparently allowing the 'org' prefix.
>
> Ok, just wondering as this is
On 11 October 2011 15:43, Hardy Ferentschik wrote:
> Hi,
>
> great, seems we are sharing the same view then.
> I will go ahead change the Architecture and Configuration chapters
> accordingly.
> It won't be in the release tomorrow, but definitely for the Final.
>
>
>>> * properties of the form org
Hi,
great, seems we are sharing the same view then.
I will go ahead change the Architecture and Configuration chapters
accordingly.
It won't be in the release tomorrow, but definitely for the Final.
>> * properties of the form org.hibernate.search.xyz are default values
>> which apply for an
Hi Hardy,
commented inline:
On 11 October 2011 14:45, Hardy Ferentschik wrote:
> hi,
>
> as you know I am reviewing the Search documentation and I keep banging my
> head against chapter
> 2 (Architecture) and 3 (Configuration).
> This two chapters are most affected by the Search 4 changes and I t
hi,
as you know I am reviewing the Search documentation and I keep banging my
head against chapter
2 (Architecture) and 3 (Configuration).
This two chapters are most affected by the Search 4 changes and I think we
need to rethink how
we want to describe the system to our users. The current doc
15 matches
Mail list logo
