Re: Major proposal: NamedList in Solr 10

[David Smiley <ds...@apache.org>]

As this is definitely SIP-worthy, I created "SIP-22 NamedList Reduction"
with an implementation plan that has already started (SimpleOrderedMap is
now a Map).
https://cwiki.apache.org/confluence/display/SOLR/SIP-22%3A+NamedList+Reduction

Please take a look everyone!

At the moment, I leave open the question of API signatures switching to
SimpleOrderedMap or further to Map.

>

Re: Major proposal: NamedList in Solr 10

[David Smiley <ds...@apache.org>]

Thanks for your input!

On Mon, Feb 10, 2025 at 2:20 PM Jason Gerlowski <ge...@gmail.com>
wrote:

> Hey David,
>
> I think reducing NamedList usage is a great idea, and I'm glad to see
> you interested in tackling that (or at least, shining light on a
> possible path forward).
>
> I'm +1 with the plan itself, but I've offered a few suggestions below
> that I think could make the writeup clearer on some points.
>
> > Several Options; pick one [from "Public Interfaces"]
>
> There are three options ("A", "B", "C") mentioned, but on a first read
> it's not entirely clear how an implementer might choose between those
> options for any particular case.  Might be worth a clarifying sentence
> here.
>

I intended to discuss that here.  My preference is B for Solr 10.  C is
more work; could defer C to Solr 11.


> > Change NamedList instantiations to SimpleOrderedMap as appropriate [from
> "Proposed Changes"]
>
> How would an implementer know when SimpleOrderedMap is an appropriate
> concrete-type?  Are there easy ways to tell, or does this require a
> detailed understanding of the code in question and whether it's
> possible for it to lead to duplicate keys?
>

Duplicate keys -- that's the main consideration.  We could experimentally
blindly do SOM and add some asserts to check for duplicate keys so we see
(in tests) where in fact we actually need a plain NamedList.  For many of
us old-timers, we already know most of the time.


> Additionally - I'm curious about the longer-term status of
> SimpleOrderedMap.  Right now, SimpleOrderedMap is required for javabin
> compatibility reasons (I think?).  But since there's interest in
> eventually removing javabin, I'd like to ask: would SimpleOrderedMap
> serve any conceptual role/purpose in a theoretical post-javabin world?
>  Or could a post-javabin world see us use "new HashMap<>()" or
> something similar instead of SOM?
>

Longer term it's a combination of Map (often LinkedHashMap) and POJOs with
annotations to aid Jackson as necessary.  I thought you would be
opinionated on this given its tight relationship with the V2 API.


> Best,
>
> Jason
>
> On Mon, Feb 3, 2025 at 2:49 PM David Smiley <ds...@apache.org> wrote:
> >
> > As this is definitely SIP-worthy, I created "SIP-22 NamedList Reduction"
> > with an implementation plan that has already started (SimpleOrderedMap is
> > now a Map).
> >
> https://cwiki.apache.org/confluence/display/SOLR/SIP-22%3A+NamedList+Reduction
> >
> > Please take a look everyone!
> >
> > At the moment, I leave open the question of API signatures switching to
> > SimpleOrderedMap or further to Map.
> >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>

Re: Major proposal: NamedList in Solr 10

[Jason Gerlowski <ge...@gmail.com>]

Hey David,

I think reducing NamedList usage is a great idea, and I'm glad to see
you interested in tackling that (or at least, shining light on a
possible path forward).

I'm +1 with the plan itself, but I've offered a few suggestions below
that I think could make the writeup clearer on some points.

> Several Options; pick one [from "Public Interfaces"]

There are three options ("A", "B", "C") mentioned, but on a first read
it's not entirely clear how an implementer might choose between those
options for any particular case.  Might be worth a clarifying sentence
here.

> Change NamedList instantiations to SimpleOrderedMap as appropriate [from "Proposed Changes"]

How would an implementer know when SimpleOrderedMap is an appropriate
concrete-type?  Are there easy ways to tell, or does this require a
detailed understanding of the code in question and whether it's
possible for it to lead to duplicate keys?

Additionally - I'm curious about the longer-term status of
SimpleOrderedMap.  Right now, SimpleOrderedMap is required for javabin
compatibility reasons (I think?).  But since there's interest in
eventually removing javabin, I'd like to ask: would SimpleOrderedMap
serve any conceptual role/purpose in a theoretical post-javabin world?
 Or could a post-javabin world see us use "new HashMap<>()" or
something similar instead of SOM?

Best,

Jason

On Mon, Feb 3, 2025 at 2:49 PM David Smiley <ds...@apache.org> wrote:
>
> As this is definitely SIP-worthy, I created "SIP-22 NamedList Reduction"
> with an implementation plan that has already started (SimpleOrderedMap is
> now a Map).
> https://cwiki.apache.org/confluence/display/SOLR/SIP-22%3A+NamedList+Reduction
>
> Please take a look everyone!
>
> At the moment, I leave open the question of API signatures switching to
> SimpleOrderedMap or further to Map.
>
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org