Hi Jody, thank you for the feedback, lost track of this one during the holidays, find my replies inline:
On Tue, Jul 23, 2024 at 12:41 AM Jody Garnett <jody.garn...@gmail.com> wrote: > Adding the priority is fine as a fallback plan (like it will work). But it > is more a band-aid than a cure. It just puts off the problem (two accessors > can have the same number and we are right back to chance). > > Some questions: > > Q: Is there anyway to tighten up the reporting so that > FeaturePropertyAccessor does not respond? It is much nicer to have an API > that requires unambiguity - only add accessors when you add new kinds of > data to query. > My understanding is that the FeaturePropertyAccessor works as the default accessor for Feature and FeatureType, but these classes themselves can be extended, which is where a custom property accessor is often needed. One option could be to refactor the inheritance architecture of the Complex Types and Complex Attributes and address potential backward compatibility issues. However, that work would be too extensive for the current scope I’m dealing with. Hence, my suggestion which provide a solution that works within the existing architecture. > > Q: Why do you need a custom property accessory? > In this particular situation, I'm dealing with the SchemalessPropertyAccessorFactory, which addresses two key aspects specific to the Schemaless Mongo community module: - When a property is requested, the type may not exist yet, so it needs to be resolved on the fly and return anyType as the type. - It supports properties that follow the dot notation, such as property1.property2.value, JSON is the core format used in this scenarios. > > If both FeaturePropertyAccessor and your customer property access can do > the job… > > If it is for performance then just adding priority will not be so good, it > is better to do something like the sorting and enable/disable that was done > for the icon factories (which are very performance sensitive). I expect it > was done with pairwise ordering which is another common pattern in > GeoTools code… > It's primarily for the functionality described above, but performance is always a concern. This is a good point; I'll need to ensure that sorting doesn’t occur each time a property is accessed. > > I am curious what your property accessor does! > > -- > Jody Garnett > > > On Mon, Jul 22, 2024 at 3:53 PM Nuno Oliveira < > nuno.olive...@geosolutionsgroup.com> wrote: > >> Hi, >> >> I've encountered an issue where a custom property accessor suddenly >> stopped working. Upon investigation, I found that the problem originates >> from the fact that the order in which property accessors are read and >> registered is random and lacks an explicit priority mechanism. This is >> usually not problematic because most property accessors will simply >> indicate that they cannot handle the provided property path. However, in my >> case, the permissive FeaturePropertyAccessor >> <https://github.com/geotools/geotools/blob/f02e34f8fce93e7620a319ef1fd9daab8ba5c67d/modules/extension/complex/src/main/java/org/geotools/data/complex/expression/FeaturePropertyAccessorFactory.java#L209> >> happens to be loaded as one of the first properties accessor, taking >> precedence over my custom property accessor. >> >> GeoTools allows extensions to register property accessors, which are >> loaded HERE >> <https://github.com/geotools/geotools/blob/1b4c81fc632b4c0a106593a957925f57861e5a9d/modules/library/main/src/main/java/org/geotools/filter/expression/PropertyAccessors.java#L32-L50>. >> As you may know, a property accessor defines how a provided property path >> (for example in a filter) should be interpreted when applied to a feature. >> GeoTools uses the first property accessor capable of retrieving the >> property value, this happens HERE >> <https://github.com/geotools/geotools/blob/1b4c81fc632b4c0a106593a957925f57861e5a9d/modules/library/main/src/main/java/org/geotools/filter/expression/PropertyAccessors.java#L55-L81> >> . >> >> To address this issue, I propose introducing a prioritization concept for >> property accessors. This would allow extensions to register property >> accessors with specific priorities, ensuring that they are evaluated before >> default permissive ones, regardless of the loading order. What I have in >> mind is the following: >> >> 1. >> >> Introduce priority constants: >> - >> >> HIGHEST_PRIORITY (0): For the most preferred property accessors. >> - >> >> DEFAULT_PRIORITY (3000): For the standard priority level. >> - >> >> LOWEST_PRIORITY (5000): For the least preferred property accessors. >> 2. >> >> Update the PropertyAccessorFactory interface: >> - >> >> Add a getPriority() method to the PropertyAccessorFactory interface >> that returns the priority of the property accessor as an integer. By >> default, this method should return DEFAULT_PRIORITY, but >> implementations can override it to provide custom priority values. >> 3. >> >> Modify FeaturePropertyAccessorFactory: >> - >> >> Adjust this class to return LOWEST_PRIORITY in its getPriority() >> method. This change indicates that this accessor is the most generic >> and >> should be used only when no higher-priority accessors are applicable. >> 4. >> >> Sort Property Accessors: >> - >> >> Implement sorting of property accessors in the PropertyAccessors >> class based on their priority. This ensures that accessors with higher >> priorities are processed before those with lower priorities. >> >> This prioritization mechanism will allow for more controlled and >> predictable behavior when working with custom property accessors in >> GeoTools. >> >> Any comments? >> Looking forward to reading your feedback, >> Nuno Oliveira >> >> -- >> >> Regards, >> >> Nuno Oliveira >> >> == >> GeoServer Professional Services from the experts! >> >> Visit http://bit.ly/gs-services-us for more information. >> == >> >> Nuno Miguel Carvalho Oliveira >> @nmcoliveira >> Technical Lead / Project Manager >> >> >> GeoSolutions Group >> phone: +39 0584 962313 >> fax: +39 0584 1660272 >> >> https://www.geosolutionsgroup.com/ >> 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 >> > -- Regards, Nuno Oliveira == GeoServer Professional Services from the experts! Visit http://bit.ly/gs-services-us for more information. == Nuno Miguel Carvalho Oliveira @nmcoliveira Technical Lead / Project Manager GeoSolutions Group phone: +39 0584 962313 fax: +39 0584 1660272 https://www.geosolutionsgroup.com/ 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