I agree, its part of a larger issue of type mapping from various differnt datastores / persistence layers. And with the new feature model and the idea of schemas / type mapping sprofiles, etc... we will be in a better place to handle these cases. But for now we are kind of stuck with what we have got.
-Justin Rob Atkinson wrote: > 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 > > !DSPAM:1004,458721e2145101460912952! > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
