Query is a class, so we can make several constructors, breaking less code.
I agree that most code will be constructing queries, so I do not expect a
lot of breakage.

aside: I looked at JDBC ResultSet and paging and it uses int
--
Jody Garnett


On Fri, 4 Sep 2020 at 11:09, Andrea Aime <andrea.a...@geo-solutions.it>
wrote:

> Hi all,
> I've tried to do the int/long switch at the FeatureSource level. It was
> not difficult, should not
> be hard for those upgrading either:
>
> https://github.com/geotools/geotools/pull/3134
>
> About the FeatureCollection changes, the proposal extends semantics of
> count in a feature collection. I cannot resource this larger change,
> those that want to push for it, will have to put actual work on it (please
> speak up if you intend to). It's also not clear what would happen if
> lenient is true, but the collection can only do precise counts, but not
> estimates.
>
> Within the limits of what I can work on, I would propose to simply
> deprecate size(), as FeatureCollection is not a java.util.Collection, and
> introduce a "long count()",
> which also nicely parallels the FeatureSource changes.
>
> Working on the FeatureSource changes made me realize there is a bigger
> problem... Query and paging.
> Right now startIndex and limit are integers, in a world where we count by
> longs, those should probably be long as well no?
> However, that class... I'm guessing a straight break is the only approach?
> Hopefully most code uses only the setters, which would not really be
> broken by the change: only the getters will require a cast or change of
> variable types.
>
> Cheers
> Andrea
>
>
> On Fri, Sep 4, 2020 at 6:30 PM Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> Sorry I was looking at FeatureSource, thinking ...
>> - FeatureSource is the priority, as it is used to do paged queries (each
>> one of which returns a feature collection).
>> - The general approach (return Integer.MAX_VALUE if needful, and provide
>> an alternate method that returns long is a good one)
>> - The estimate size discussion is useful, since it only really becomes an
>> issue when we have very large numbers of features, although
>> estimating based on index would be possible
>>
>> Okay putting that together how about:
>>
>> /**
>>  * Returns the number of elements in this collection. If this collection
>> contains more than Integer.MAX_VALUE elements, returns Integer.MAX_VALUE.
>>  * Please note this operation may be expensive when working with remote
>> content.
>>  * @see java.util.Collection#size()
>>  * @return the number of elements in this collection
>>  */
>> int size();
>>
>> /**
>>  * Estimates the number of elements in this collection, to be used when
>> {@link #size()} is limited by Integer.MAX_VALUE or is too expensive when
>> working with remote content.
>>  * @parm lenient Use true to allow a size estimate in cases where exact
>> count is expensive due to size or distributed content
>>  * @return the number of elements in this collection
>>  */
>> long size( boolean lenient )
>>
>> The use of lenient above gives a different method signature and is in
>> agreement with CRS.decode method usage.
>>
>> --
>> Jody Garnett
>>
>>
>> On Wed, 2 Sep 2020 at 10:55, Andrea Aime <andrea.a...@geo-solutions.it>
>> wrote:
>>
>>> Hi Jody,
>>> I like this road, works fine for FeatureSource.
>>> What about FeatureCollection though? It's already using "int size()",
>>> from the interface:
>>>
>>> /**
>>>  * Please note this operation may be expensive when working with remote 
>>> content.
>>>  *
>>>  * @see java.util.Collection#size()
>>>  */
>>> int size();
>>>
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> On Wed, Sep 2, 2020 at 7:45 PM Jody Garnett <jody.garn...@gmail.com>
>>> wrote:
>>>
>>>> Here is another softer approach:
>>>> /**
>>>>  * @return Returns the number of features in this collection, if this
>>>> collection contains more than Integer.MAX_VALUE elements, returns
>>>> Integer.MAX_VALUE.
>>>>  * @deprecated Please use count()
>>>>  */
>>>> public int getCount();
>>>>
>>>> public long size();
>>>>
>>>> This gives us a clear api migration and does not immediately break
>>>> projects when they upgrade. The size() name matches how Collections.size()
>>>> handles a size greater than the range of Integer.MAX_VALUE.
>>>>
>>>> --
>>>> Jody Garnett
>>>>
>>>>
>>>> On Wed, 2 Sep 2020 at 06:43, Andrea Aime <andrea.a...@geo-solutions.it>
>>>> wrote:
>>>>
>>>>> Hi, any other opinion on this?
>>>>>
>>>>> Personally I would not like breaking all existing store
>>>>> implementations and clients, for a "clean break" it seems quite bloody :-D
>>>>> But Jody suggests to go that way.
>>>>>
>>>>> Some tie breaker, or even multiple votes leading to another tie, would
>>>>> be appreciated, ha!
>>>>>
>>>>> Cheers
>>>>> Andrea
>>>>>
>>>>> On Thu, Aug 27, 2020 at 11:16 PM Andrea Aime <
>>>>> andrea.a...@geo-solutions.it> wrote:
>>>>>
>>>>>> Hi Jody,
>>>>>> comment inline.
>>>>>>
>>>>>> On Thu, Aug 27, 2020 at 11:06 PM Jody Garnett <jody.garn...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> We are just about to start a new release cycle, API changes are a
>>>>>>> short-term pain, but the most maintainable approach long term.
>>>>>>>
>>>>>>> As for the change, how about returning a returning long? Existing
>>>>>>> client code that used integrer would be easy to update.
>>>>>>>
>>>>>>> long count = featureSource.getCount(query);
>>>>>>>
>>>>>>> Or:
>>>>>>>
>>>>>>> int count = (int) featureSource.getCount(query);
>>>>>>>
>>>>>>>
>>>>>> We can gauge how easy it is by doing the switch in GT/GS...
>>>>>> Maybe it could be done as a refactor... but I cannot imagine exactly
>>>>>> how yet. Closest thing to something working may be:
>>>>>>
>>>>>> 1) Rename existing getCount to getCountOld via refactor
>>>>>> 2) Add a new method called getCount, returning long, make it
>>>>>> abstract, have a default implementation of getCountOld delegating to
>>>>>> getCount
>>>>>> 3) Fix all implementations, switching them from getCountOld to
>>>>>> getCount
>>>>>> 4) Inline getCountOld, that should fix all calling points
>>>>>>
>>>>>> Hopefully that should not be too much work, I hope there are few
>>>>>> implementations of FeatureSource/Collection but many
>>>>>> client code calls using them.
>>>>>>
>>>>>>
>>>>>>> If you really want Java 8 has Math.toIntExact method, that produces
>>>>>>> an exception if the long is out of range:
>>>>>>>
>>>>>>> int count = Math. toIntExact( featureSource.getCount(query) );
>>>>>>>
>>>>>>>
>>>>>> That would also work yes
>>>>>>
>>>>>> Cheers
>>>>>> Andrea
>>>>>>
>>>>>> == GeoServer Professional Services from the experts! Visit
>>>>>> http://goo.gl/it488V for more information. == Ing. Andrea Aime
>>>>>> @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
>>>>>> Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
>>>>>> 8844549 http://www.geo-solutions.it
>>>>>> http://twitter.com/geosolutions_it
>>>>>> ------------------------------------------------------- *Con
>>>>>> riferimento alla normativa sul trattamento dei dati personali (Reg. UE
>>>>>> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>>>>>> precisa che ogni circostanza inerente alla presente email (il suo
>>>>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>>>>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>>>>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>>>>>> operazione è illecita. Le sarei comunque grato se potesse darmene 
>>>>>> notizia.
>>>>>> This email is intended only for the person or entity to which it is
>>>>>> addressed and may contain information that is privileged, confidential or
>>>>>> otherwise protected from disclosure. We remind that - as provided by
>>>>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of 
>>>>>> this
>>>>>> e-mail or the information herein by anyone other than the intended
>>>>>> recipient is prohibited. If you have received this email by mistake, 
>>>>>> please
>>>>>> notify us immediately by telephone or e-mail.*
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Regards, Andrea Aime
>>>>>
>>>>> == GeoServer Professional Services from the experts! Visit
>>>>> http://goo.gl/it488V for more information. == Ing. Andrea Aime
>>>>> @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054
>>>>> Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339
>>>>> 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it
>>>>> ------------------------------------------------------- *Con
>>>>> riferimento alla normativa sul trattamento dei dati personali (Reg. UE
>>>>> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>>>>> precisa che ogni circostanza inerente alla presente email (il suo
>>>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>>>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>>>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>>>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>>>> This email is intended only for the person or entity to which it is
>>>>> addressed and may contain information that is privileged, confidential or
>>>>> otherwise protected from disclosure. We remind that - as provided by
>>>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of 
>>>>> this
>>>>> e-mail or the information herein by anyone other than the intended
>>>>> recipient is prohibited. If you have received this email by mistake, 
>>>>> please
>>>>> notify us immediately by telephone or e-mail.*
>>>>>
>>>>
>>>
>>> --
>>>
>>> Regards, Andrea Aime
>>>
>>> == GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
>>> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
>>> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
>>> http://www.geo-solutions.it http://twitter.com/geosolutions_it
>>> ------------------------------------------------------- *Con
>>> riferimento alla normativa sul trattamento dei dati personali (Reg. UE
>>> 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
>>> precisa che ogni circostanza inerente alla presente email (il suo
>>> contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
>>> riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
>>> messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
>>> operazione è illecita. Le sarei comunque grato se potesse darmene notizia.
>>> This email is intended only for the person or entity to which it is
>>> addressed and may contain information that is privileged, confidential or
>>> otherwise protected from disclosure. We remind that - as provided by
>>> European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
>>> e-mail or the information herein by anyone other than the intended
>>> recipient is prohibited. If you have received this email by mistake, please
>>> notify us immediately by telephone or e-mail.*
>>>
>>
>
> --
>
> Regards, Andrea Aime
>
> == GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa
> (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
> http://www.geo-solutions.it http://twitter.com/geosolutions_it
> ------------------------------------------------------- *Con riferimento
> alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 -
> Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni
> circostanza inerente alla presente email (il suo contenuto, gli eventuali
> allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i
> destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per
> errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le
> sarei comunque grato se potesse darmene notizia. This email is intended
> only for the person or entity to which it is addressed and may contain
> information that is privileged, confidential or otherwise protected from
> disclosure. We remind that - as provided by European Regulation 2016/679
> “GDPR” - copying, dissemination or use of this e-mail or the information
> herein by anyone other than the intended recipient is prohibited. If you
> have received this email by mistake, please notify us immediately by
> telephone or e-mail.*
>
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to