ionStage instead because many of the newer libs we use support this.
If Ignite 3 went this way it'd remove a lot of boiler plate/wrapper that we
wrote to get what you're suggesting here.
Regards,
Courtney Robinson
Founder and CEO, Hypi
Tel: ++44 208 123 2413 (GMT+0) <https://hypi
Prefer 1 from Teras' response. Specifying index name is preferred.
I've seen customers do idx(A,B) and idx(B,A) where semantics change between
the two.
Regards,
Courtney Robinson
Founder and CEO, Hypi
Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io>
<https://hypi.io>
ht
ncaughtExceptionHandler
and ThreadFactory
<https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadFactory.html>
that
we have various metrics and customisations around. If the only option is
the default ForkJoinPool#commonPool we'd lose this when eventually moving
to 3.
Regard
I think since Calcite brings it in already then your arguments make sense.
Would it be pinned to the same version as Calcite? Risk NoSuchMethodError
at runtime if not.
+1
On Mon, Aug 9, 2021 at 9:56 AM Alexander Polovtcev
wrote:
> Zhenya, Courtney, Andrey,
>
> What do you think about my argument
Also, what impact will this have on peer class loading? Something I think
shading also resolves
On Thu, Aug 5, 2021 at 7:05 PM Courtney Robinson
wrote:
> Can I suggest shading Guava?
> Guava and Netty are two notorious libraries for version conflicts because
> of their popul
;d +1 this but really only if it will be shaded.
Regards,
Courtney Robinson
Founder and CEO, Hypi
Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io>
<https://hypi.io>
https://hypi.io
On Thu, Aug 5, 2021 at 5:56 PM Zhenya Stanilovsky
wrote:
>
> alexpolovtcev please clarify
e the stats maintained and if a query plan is cached based on
some stats, is it not possible to invalidate the cached plan periodically
or based on statistics changes?
Regards,
Courtney Robinson
Founder and CEO, Hypi
Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io>
<https://hypi.io>
htt
ene just for it.
> > I think we should have native support for full-text search queries
> and/or a
> > custom SQL function.
> >
> > E.g. Postgres syntax for FTS queries [1] is completely different to
> "LIKE"
> > operator.
> >
> > [1]
> >
&g
ieldsQuery to a cache that has nothing to do with the
cache being queried? When I first started with Ignite years ago, this was
beyond confusing for me. I'm trying to run select x from B but I pass this
to a cache called DUMMY or whatever arbitrary name...
On Fri, Jul 23, 2021 at 4:05 PM Co
ight choice
Calcite doesn't have support for Solr but it has an ES adapter which is
what we modified to support Solr.
Regards,
Courtney Robinson
Founder and CEO, Hypi
Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io>
<https://hypi.io>
https://hypi.io
On Sat, Jul 24, 2021 at 1:5
e part in the rest of the query. It's
probably more complex than this for Ignite but that's one possible route
but we generate queries like select x from T0 where term(args to solr term
query) AND ...
Regards,
Courtney Robinson
Founder and CEO, Hypi
Tel: ++44 208 123 2413 (GMT+0) <
configured in a different way,
> which makes Ignite configuring a bit simpler.
> Sorry, for now, I have no answer on your performance concerns, this part of
> Ignite-3 slipped from my radar.
>
No worries. I'll wait and see if anyone else suggests something. Its
getting a lot wo
ing
with the growth of tables. Are there any provisions in Ignite 3 for
ensuring startup time isn't proportional to the number of tables/caches
available?
Those are the key things I can think of at the moment. Val and others I'd
love to open a conversation around these.
Regards,
Courtney Robinson
Founder and CEO, Hypi
Tel: ++44 208 123 2413 (GMT+0) <https://hypi.io>
<https://hypi.io>
https://hypi.io
13 matches
Mail list logo
