Agree on this, I wouldn't be surprised if there is a JIRA for it already, have
you checked? Pass-through params are quite useful, so we could provide a
special prefix 'x.' that would still be allowed, e.g. "x.myCustom=foo"
Jan
> 12. nov. 2021 kl. 00:06 skrev Shawn Heisey :
>
> On 11/4/2021 4:
On 11/4/2021 4:42 PM, Shawn Heisey wrote:
This is possibly a pipe dream:
Most of us are probably already aware that the original API ignores
unknown parameters sent in with a request. Some of our users utilize
this for log parsing -- by including some custom parameter on the
request that So
+1
8x will be in bugfix-only mode after the 8.11 release, so v2 bugfixes are ok,
but feel free to innovate and break back-compat in 9.x!
Jan
> 8. nov. 2021 kl. 13:39 skrev Eric Pugh :
>
> Jason G and I were chatting about if we need to back port to the 8X line
> every change made to enhance t
Jason G and I were chatting about if we need to back port to the 8X line every
change made to enhance the V2 APIs, and my thought was that part of the
“experimental” tag is that we could just work in the main code base. This
would make it easier to move quicker and not always have that “how is
Once I get the core-container split out into it's own
provider/service/whatever started by a context listener, we should do v3 as
a servlet giving us a clean slate, and easy access to verbs. I suspect v2
was made much more difficult by the fact that it had to co-exist with a lot
of other code insid
+1 to experimental
If we want to be more standards-based, embrace OpenAPI and perhaps more
standardized RBAC frameworks, then I believe there will be a v3 API based on
JAX-RS or something, with more active use of http verbs.
While v2 is harder for devs to use and remember, it has somewhat better
I can live with “experimental” ;-)
> On Nov 4, 2021, at 6:42 PM, Shawn Heisey wrote:
>
> On 11/4/21 1:20 PM, Jason Gerlowski wrote:
>> With that in mind, I think the next steps here should probably be to:
>>
>> 1. decide what label or term we want to go with ("evolving"?
>> "experimental"? "bet
On 11/4/21 1:20 PM, Jason Gerlowski wrote:
With that in mind, I think the next steps here should probably be to:
1. decide what label or term we want to go with ("evolving"?
"experimental"? "beta"?), and
2. figure out what the best way to publicize change in policy.
For (1) my vote is probably
I raised the point as a general concern but I'm quite willing to accept the
clear majority opinion. Definitely not anywhere near veto :)
On Thu, Nov 4, 2021 at 3:20 PM Jason Gerlowski
wrote:
> Alright, it seems like there's general agreement that we should
> designate v2's evolving nature in som
Alright, it seems like there's general agreement that we should
designate v2's evolving nature in some way, and that this should allow
us to break backcompat if necessary on v2 going forward. There were
at least 8 voices in favor with the only disagreement being Gus who
expressed concern on the ba
No relation to manning or the author but there's a MEAP book on sale
about OpenAPI -->
https://twitter.com/LukasRosenstock/status/1455915170614677507
On Mon, Nov 1, 2021 at 8:40 AM Jason Gerlowski wrote:
>
> I don't know OpenAPI well enough to have an opinion on whether it's
> right for Solr, exc
I don't know OpenAPI well enough to have an opinion on whether it's
right for Solr, except to say that if we do want OpenAPI then an
"experimental" designation sounds helpful for giving us flexibility to
change our APIs as necessary.
I recently created SOLR-15734 as an umbrella for tracking and
di
Agree. Solr too often suffers from “not invented here” syndrome.
OpenAPI is closer to REST, , i.e. using the http DELETE verb for deleting
resources etc. I think the only selling-point for v2 was that it allows mixing
lots of actions like adding and deleting in the same atomic request. But if
d
I'm definitely +1 on the OpenAPI requirement for v2 going forward.
On Fri, Oct 29, 2021 at 12:04 PM Timothy Potter
wrote:
> I actually think that should be a hard requirement for the "next" API
> ... if v2 is so different and awkward compared to a broadly adopted
> standard, I'd say that's a sho
I actually think that should be a hard requirement for the "next" API
... if v2 is so different and awkward compared to a broadly adopted
standard, I'd say that's a short-coming of the v2 design. If we're
going to keep rolling out APIs that no standardized tooling supports,
just stick with v1, our
I did try to write a OpenAPI specification for V2, and discovered how much
customization/specifics I would have to do, and gave up because we were so very
different. With the “experimental” tag, we could evolve towards the OpenAPI
spec standards if folks wanted to ;-)
> On Oct 29, 2021, at 11
Does the v2 API support OpenAPI? I looked over the docs and it seems
like not, which is a shame. OpenAPI
(https://swagger.io/specification/) opens up a mature ecosystem of
tooling. The _introspection endpoint seems nice but if automated tools
can't understand it, then our users can't auto-generate
+1 to experimental (java level).
In user facing docs and tutorials, we can encourage use, with just a minor note
somewhere that it may still change.
When users report bugs there will always be a workaround — use v1 until next
release..
Jan Høydahl
> 27. okt. 2021 kl. 23:18 skrev David Smiley :
I agree that *very* few users use V2. Ok I do at work but it's maybe one
API endpoint so whatever. We should free ourselves from the burdensome
constraints of back-compat until V2 is sufficiently ready, whenever that
is. So I agree with labeling it experimental and we can elaborate on that
is th
I'm +1 to ensuring V2 APIs are ready by everyone's definition before 9.0.
Hence I'm +1 to treat it as a blocker. However, if others feel we shouldn't
hold it up, I'll likely not care about V2 APIs for another 2 years (by 10.x
timeframe).
On Thu, 28 Oct, 2021, 2:12 am Ishan Chattopadhyaya, <
ichatt
My main concern is if we don't put it out there as front and center and
hence don't allow users to use it, what motivation does that leave for
developers to continue working on it? If it is not fully ready, some of us
don't want it to be out there prominently for users to use it. Hence, if I
can't
> For whatever functionality is exposed via V2 APIs, it is ready.
You lose me right around here Ishan. IMO exposing functionality makes
a particular V2 API "usable", it doesn't necessarily make it "ready".
"Ready" implies some confidence that I personally don't have without
our test randomization
I thought about fixing SOLR-14795 when I documented the v2 apis, and the amount
of change and the “ugh, it will be hard to have back compatibility” led me to
not trying to move any of the sub tickets forward.
If the V2 version of the API’s is more open to change, then it would make it
easier
Hmm,
My understanding was that V2 Config API is part of the V2 APIs and
relevant discussion, so when the questions about gaps came up, I felt
it was relevant. Perhaps it is less relevant than I thought. I will
let others judge and apologize if I introduced too much noise.
Regards,
Alex.
On We
> But I think there's a strong case that these users are a tiny
> tiny minority out there: see the past lack of v2 docs, SolrJ support,
> mailing list traffic or bug reports on v2, etc.
>
Well I'm guilty of having documented it in documentation I wrote or
significantly modified, which ironically
Alex, these seem to be issues with config API (and should be solved), while
this discussion is about v2 version of all APIs. What is the relevance here?
On Wed, 27 Oct, 2021, 9:24 pm Alexandre Rafalovitch,
wrote:
> I feel that the summary of my umbrella case (SOLR-14795) qualifies for
> this:
>
I feel that the summary of my umbrella case (SOLR-14795) qualifies for this:
"
General issues with output being materialized schema:
* parameters have already been resolved and are not indicated
* empty keys may not be output (e.g. dataDir)
* default parameters will be output that are not in solrc
> some aspects of the v2 API are clearly downgrades from the v1 API.
Please open a JIRA, and we can discuss there. If there's already any
discussion, please point to them.
> My big concerns are purely "cosmetic" (HTTP Methods, API paths, HTTP
Status Codes, etc).
Patches welcome. Or if you open a
> While that does mean that users will be hesitant to move to it for the
time
> being, isn't that kind of the point since we are planning on changing
things?
Exactly, that's the point of major release upgrades. Users will remain
sceptical of moving production to 9x during the early few releases an
Personally I think, while it made a lot of improvements, some aspects of
the v2 API are clearly downgrades from the v1 API.
I do think we should move towards deprecating the v1 API, but not until we
have a solid (and documented of course) v2 or v3 API.
Instead of worrying about v3, I think we shou
> unfortunately it's been released without that moniker for a long time ... we
> may need to go v3 if we want to change things since people will
> understandably have written code against it.
The idea of breaking "existing v2 users" is definitely a sticking
point. But I think there's a strong c
> While the v2 has been out for a long time, do we actually have evidence
that it is widely used and has significant code written against it?
I don't think anyone uses V2 APIs. No one wants to use undocumented APIs.
> I worry that deciding to go with v3 it going to prevent any forward
progress
I
While the v2 has been out for a long time, do we actually have evidence that it
is widely used and has significant code written against it?
When I look at various components/packages that have been written around Solr,
I don’t see the v2 API used. For example, Project Blacklight, a UI for Sol
And I think v1/v2 should be split into their own servlets leveraging common
code by calling utilities, or composing with other objects rather than
inheriting and getting in each other's way. I think v2 could change a lot
so experimental seems appropriate, but unfortunately it's been released
withou
I felt that V2's lack of support for defaults was a serious architectural
issue that is hard to just close eyes on.
Regards,
Alex
On Tue., Oct. 26, 2021, 3:17 p.m. Eric Pugh, <
ep...@opensourceconnections.com> wrote:
> I’d very much like to see this as well.
>
> I’ve been thinking that I woul
I’d very much like to see this as well.
I’ve been thinking that I would look to migrate the Solr Admin to using the v2
API, and I suspect it will identify any number of gaps/areas of improvement in
the v2 API itself.
> On Oct 26, 2021, at 3:10 PM, Jason Gerlowski wrote:
>
> Hi all,
>
Hi all,
I'm starting this thread to highlight a subject that came up in the
recent "Solr 9.0 Release Blockers" thread: our v2 API. As a TL;DR,
should the v2 API be considered "experimental"?
We haven't explicitly called the v2 API experimental up to this point,
but I'd argue that in essence it a
37 matches
Mail list logo
