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
