Hi Andrea - I was talking with Ian about your postgis fixes.
He did not understand where we were running into difficulty on the JDBC side of
things.
Here is my understanding:
- You have a FeatureReader that holds and manages a resultset (this class
delegates to AttributeIO parse objects that handle each column)
- Shapefile has a AttributeReader for each file
If we make a one to one corraspondance between AttributeReader and Result set we
can make both these visions work out. Your FeatureReader would become very
small containing just the AttribtueReader and your FID stratagy.
This would still allow IanS ideas on AttributeReader based opperations:
- AttributeReader aware Filter implementation
- Cross DataStore joins at the AttributeReader level
Where things got messy with JDBC AttribtueReaders in the past was having several
of them manage one result set. Your AttributeIO parse objects don't have to
manage the result. Apparently IanS is quite happy having AttribtueReaders
delegate parsing.
Cheers,
Jody
IanS whats the postgis fixes ?
jgarnett JDBC DataStores kind of got lost in complexity - they reached a point
where only every second delete would work.
IanS how does that relate to shapefile?
IanS sorry if I missed something here
jgarnett The code would work on Oracle and not on postgis. They had
AttributeReaders sending notifications to a shared QueryData object holding the
result set.
jgarnett They were doing all of this to try and track the use of
AttributeReaders in shapefile.
IanS huh?
jgarnett What has happended is that aaime has gone in and built a replacement
jgarnett where AttributeReaders are not used.
jgarnett She has the FeatureReader holding the Result set.
IanS he
jgarnett So ifyou wanted to do your join opperation based on AttributeReaders I
will have to reject this fix.
jgarnett It is the push and pull between file and database again
IanS my point behind attribute readers was to allow joins below Features and to
hopefully be able to obtain some common functionality - like reading only the
attributes required from the query
jgarnett I know - they were talking about doing joins above the Features in
todays irc
IanS yes, we talked about that before the data redesign
IanS so what do you need?
jgarnett So I would like everyone back on the same page again; if we want joins
below the features I will have to make them an API they can maintain.
jgarnett If I don't they are going to ignore AttributeReaders and we will not be
able to relize your idea of joins bellow the features.
IanS or common behavior from query
jgarnett Or the filters that only parse what they need. The database guys can't
see the need since they check the filter first and only drag across what is needed.
IanS you mean the filter gets transformed to sql and the db does the proper selects
jgarnett I mean that they hunt throught he filter and find what attributes it
needs - and then only makes requests for those attributes.
jgarnett They preprocess the filter (or at least the bit of the filter they
cannot encode into sql) and only request the attribute they need.
IanS that could be duplicated in shapefile, but it would be reusable if another
api consumed a filter and an attributereader and then did the same conceptually
IanS again, the main reason for the abstraction was to unload some of the burden
from the DataStore (DataStore simply presents what it has and allows access to
it in a common way)
jgarnett I do understand how AttributeReaders work; my problem is that we are
losing the database people Do you have any suggestions on how to get everyone
back together?
IanS I guess I don't know enough JDBC to know what the problem is...
jgarnett The database people seem content to implement FeatureReader.
jgarnett Implementing AttributeReader was hard for them; and did not provide any
benifit.
IanS wouldn't attributeReader be a wrapped ResultSet ?
jgarnett This is where we lost them; they made an attribute reader for each kind
of attribute they had.
IanS well that was silly 
jgarnett So for one result set they would have 3 or 4 AttributeReaders attacking
it; they used events to try and make all these AttributeReaders work togther.
jgarnett And finally failed.
jgarnett I just relized today (in this irc) that what may have been better is to
have one AttributeReader per result set.
IanS maybe I'm a bit naive, but it would seem the base functionality would be
the same for all JDBC stores
jgarnett What aaime has done is made this beast - and called it a FeatureReader.
IanS oh, perhaps I should have spoken up several months ago, that was part of my
whole architectual premise
IanS I see AttributeReader as a gt2 adapter, to make file-based data and JDBC
data more of peers
jgarnett They only did this in the last couple of weeks - they have been
suffering since decemeber though
|<-- polio has left freenode ("ChatZilla 0.9.52B [Mozilla rv:1.6/20040113]")
jgarnett What everyone else understood was that an AttributeReader would parse
something - the JDBC types made an attributeReader per column
jgarnett The idea being that they could change the AttributeReader for their
geometry column to parse WKT or WKB
IanS the AttributeReader can _always_ delegate its responsabilities
IanS like shapefiles, column 0 reads shp, columns 1-n read dbf
jgarnett So we may have a way forward here.
jgarnett If we recast aaime featureReader as a single AttributeReader everything
should be fine?
IanS hmmm, as long as there are no technical difficulties
IanS that is, with JDBC interaction
jgarnett Anything is better then the difficulties they just went through.
jgarnett I think all that is needed is a single class that holds and processes a
result set. (which I could draw a picture).
IanS and depending upon the AttributeType columns, does the appropriate
ResultSet marshalling
jgarnett We may have to move this conversation to email - I think we are going
to go over the same points again with Andrea.
jgarnett I did not understand that.