I think the problem is rather bigger then just temporal types, but the solution is at least common.
There needs to be an abstraction between the persistence layer, the in-memory model and the output schema. For example, a database column with string values "2006" etc should be able to be treated as something bound to a range of more or less specialised GML types, depending on interpretation. Likewise, year + month + day columns could be bound to a single date. Different underlying persistence models will undoubtedly have different query performance - but thats OK too. This is however a simple case of the requirement to use the target schema to define the object type, and then handle the mapping to this type, rather than interrogating the persistence layer and trying to infer the intent. This "type injection" concept allows configuration, target schema, or reflection to determine the type, in that order, with a graceful fall-through to the current defaults. It also allows us to handle the xs:anyType we find in various schemas. What I dont yet have a handle on - (only just got gt trunk to build finally) is how far we are from this, but it seemed that much of the groundwork was in place. Putting in an ad-hoc fix for one particular type would just get in the way of the single simple solution, which may be a better way forward. i.e if you cant live with a Java.util.Date for now, push for a more useful feature model first. Rob Chris Holmes wrote: > As someone who's put too much time in to the temporal attributes with > no real success, I'm +1 to any changes to improve it. It became a > mess, that we never managed to properly solved. I'd say feel free to > even just drop TemporalAttributeType and replace it with something > more sensible, even if it's more than one class. At one time I > remember thinking a few classes with a common superclass could have > been useful. I'm too far from the code now, but updates to it have my > blessing, as most any change to it will likely be an improvement. > Just be sure to test against cite 1.0 tests as well. > > Chris > > Justin Deoliveira wrote: >> Hi all, >> >> During my battle with wfs1.1 cite tests, one of the largest problems has >> been handling dates properly. One of my major problems is that >> TemporalAttributeType hard codes its class binding to a java.util.Date. >> >> I need it to maintain the actually class passed in by whomever creating >> the attribute. For instance, java.sql.Date, java.sql.Timestamp are used >> to format dates so that they are jdbc friendly. Without them a normal >> date will blow up. >> >> So, I would like to add an additional constructor to >> TemporalAttributeType to take the actual class of the type bindings. As >> far as I can tell with just running the geotools tests this does not >> impact much except for mif datastore. I have created a jira task with >> the necessary patches. >> >> http://jira.codehaus.org/browse/GEOT-1075 >> >> -Justin >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ------------------------------------------------------------------------ > > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
