[infinispan-dev] Which QueryBuilder ?

Sanne Grinovero sanne at infinispan.org
Wed Oct 9 09:31:48 EDT 2013


On 9 October 2013 13:30, Adrian Nistor <anistor at redhat.com> wrote:
> Hi Sanne and Martin,
>
> these come from different products.

No they come from different projects, but are part of the same product.

> Would they really appear in the same documentation and javadoc?

As far as I understood, and unless you do something about it, yes.

> Are usually used in different contexts too,
> although there might be users wanting to use both HS QB and ISPN QB in
> the same context, so to ease their pain I suggest using DslQueryBuilder
> in ISPN. Would that fit?

I don't think we should name things explicitly as DSL.

> But if we start on this route should we also do something about
> org.infinispan.query.dsl.Query?

Right, that's probably the culprit. If we rename that to something
which better expresses the simplified/limited form, it might directly
solve the problem of naming its builder.
Something on the lines of Criteria / Filtering ?
I primarily see it as a Filter Stack, and if we keep it conceptually
close to that, it makes it easier for the planned retro-fitting in the
MR framework.

> I wish we could do something about
> org.infinispan.configuration.cache.ConfigurationBuilder /
> org.infinispan.client.hotrod.configuration.ConfigurationBuilder and
> several other examples of colliding names but I guess it's too late for
> them.

You still have the power to address it.
It's quite late yes, but it's too late only after it's released.
Releasing in this shape is imho very bad.

Sanne

>
> Adrian
>
> On 10/08/2013 06:32 PM, Martin Gencur wrote:
>> Right Sanne,
>> it's already starting to be a documentation problem for the product.
>> It's really confusing unless you developed one of these APIs and
>> precisely know the differences :) Any time there's a code snippet, it
>> must contain the package (usually this is not needed), but even then
>> it's easy to get confused.
>>
>> Martin
>>
>>
>> On 3.10.2013 16:48, Sanne Grinovero wrote:
>>> On 3 October 2013 14:10, Adrian Nistor <anistor at redhat.com> wrote:
>>>> I know, was just joking. Anyway, I don't see any confusion having two
>>>> classes with the same name.
>>> It's going to be hard enough to explain to people why we are providing
>>> two different approaches, if we can't even think of a different name
>>> to properly highlight the different usage then we have a problem.
>>>
>>> Try figuring the forum / support question "I'm using QueryBuilder on
>>> Infinispan 7.3 and this happens... "
>>>
>>> The javadoc index will have it listed twice -> annoying.
>>>
>>> Google for "QueryBuilder Infinispan" -> annoying
>>>
>>> Or try figuring out the documentation:
>>>
>>> # Chapter 5: Queries.
>>> There are two approaches to run Queries in Infinispan. Either you use
>>> the QueryBuilder, which provides simple domain oriented properties and
>>> can work both in embedded and remote mode, or you use the more
>>> powerfull QueryBuilder.
>>>
>>> # 5.1 QueryBuilder
>>> blah blah
>>>
>>> # 5.2 QueryBuilder
>>> blah blah
>>>
>>>
>>> If they are different, the should really have different names, even
>>> just to avoid confusion among ourselves when talking about hem. If you
>>> feel they're the same, the interesting alternative is to literally
>>> merge them in one single interface, potentially exposing multiple
>>> methods.
>>>
>>> Sanne
>>>
>>>> On 10/03/2013 02:29 PM, Emmanuel Bernard wrote:
>>>>> It's already productized code.
>>>>>
>>>>> On Thu 2013-10-03 14:16, Adrian Nistor wrote:
>>>>>> I would suggest renaming the old one :))
>>>>>>
>>>>>> On 10/02/2013 11:13 PM, Sanne Grinovero wrote:
>>>>>>> It seems we have now 2 different interfaces both names "QueryBuilder"
>>>>>>> when using Infinispan Query.
>>>>>>> One is coming from Hibernate Search, and represents the "classic" way
>>>>>>> to build queries for Infinispan Query in embedded mode.
>>>>>>>
>>>>>>> The other one is new, and represents the simplified approach, also
>>>>>>> implemented for remote queries.
>>>>>>>
>>>>>>> Could we find an alternative name for the new API?
>>>>>>>
>>>>>>> It's certainly going to be confusing, even more when we'll have to
>>>>>>> document the differences, and which one is more suited for one use
>>>>>>> cases vs. another.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Sanne
>>>>>>> _______________________________________________
>>>>>>> infinispan-dev mailing list
>>>>>>> infinispan-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> infinispan-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


More information about the infinispan-dev mailing list