On 13 December 2012 14:02, Andrea Aime <[email protected]> wrote: > On Thu, Dec 13, 2012 at 12:06 PM, Fernando Gonzalez > <[email protected]> wrote: >> >> Hi. >> >> >> For most data stores we expect them to handle this natively based in an >> >> index - what datastore were you testing with ? >> >> I'm using IndexedShapefileDataStore, but the file does not have an >> index, which I guess may be pretty common. > > > And yet this is strange, since the indexed store can create a feature id > index (the .fix file) > unless told otherwise.
Just for info, I think that the FidIndexer is only used if a FeatureReader is obtained with a Query containing an Id filter as a parameter. In gvtools we're obtaining a FeatureSource instead. I'll try to get a FeatureReader as described before to see if the fidfilter is managed natively as Jody says. > >> >> >> > >> > This kind of patch was already tried, but it broke geogit-versioned. >> > Have a look here for a discussion... maybe someone has time to figure >> > out a >> > way to solve the issue? >> > >> > http://jira.codehaus.org/browse/GEOT-3986 >> >> The patch you submitted there is the perfect implementation of what I >> was actually proposing. It's a pity that it breaks the build because >> it really makes the difference in terms of speed. >> >> Unfortunately, I haven't been able to compile geogit-versioned on >> master and reproduce the broken build to take a look. >> >> So, comparing the ID of the Identifiers[1] works, but checking their >> equality through contains()[2] does not. This happens because there is >> an implementation of Identifier that checks more things than the >> getID() in the equals(), right? Isn't it inconsistent with Identifier >> javadocs[3]? ResourceIdImpl is the only one that I've found that >> checks "more things" than the getID() in the equals. Eventually, the >> filter may return true for ResourceIds that are not equals() but that >> share the ID. > > > No, you can check more than just the id, a class can implement an > interface but have several more attributes used in equality. > However, given how it breaks, it _may_ be that it does not implement > correct hashcode/equals, or that there is an expectation that when > comparing to another implementation the equality would still > work, which is not a warranted assumption. > > Unfortunately I could not get any feedback from the geogit developers > back then, and it seems not even now... maybe we should just kick > that module out of the build. Not sure, an "unsupported" module that is indeed not supported (at least for this issue) and that is keeping some improvements from being included in the code doesn't seem like an ideal situation. But, maybe it's not the module's fault and it is exposing a defect present in other parts of the code. Just theory, as I said, I'm unable to compile. Am I the only one unable to do it? I just run mvn eclipse:eclipse and imported the project in eclipse, and it seems like the geogit-core and guava dependencies are not right. Any help appreciated. Regards. > > Cheers > Andrea > > -- > == > Our support, Your Success! Visit http://opensdi.geo-solutions.it for more > information. > == > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ GeoTools-Devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
