> Right now the project is running a fork of geotools to have the following
>> fix (from #997 <https://github.com/geotools/geotools/pull/997>):
>>
>>          Date converted = null;
>>          if (target == PostGISDialect.XDate.class) {
>>              converted = Converters.convert(expression.evaluate(null),
>> Date.class);
>>          }
>>          if (converted != null) {
>>              return converted.getTime();
>>         } else {
>>              return super.evaluateLiteral(expression, target);
>>         }
>>
>> I rejected this fix, since it violated the API contract (by returning a
>> Date rather than the requested XDate). The quickest thing I can think of is
>> to make XDate a real class and write a converter that handles it
>> appropriately.
>>
>
> Is there anywhere an explanation of why things are not working now? XDate
> there is a plain jane subclass of Date.class,
> adding nothing extra.
>


Looking at the test case, it is messing with the calendar times before the
GregorianCalendar calendar:

         GregorianCalendar cal = new GregorianCalendar();
         cal.clear();
         cal.set(-500, 0, 1);
         java.util.Date d = cal.getTime();
         long ms = d.getTime();
         ...
         // to avoid a timezone offset bug in the converter framework at
the time
         // of this writing, use the sql types to avoid conversion...
         SimpleFeature f = (SimpleFeature) writer.next();
         f.setAttribute("d", new java.sql.Date(ms));
         f.setAttribute("dt", new java.sql.Timestamp(ms));
         f.setAttribute("t", new java.sql.Time(ms));
         writer.write();

The pull request seemed to have changes a bit all over the place, but I
> cannot figure out how they are working toghether
> to solve the issue
>


I agree it is not obvious what the above code is up to, what I would like
is a summary of what is trying to be solved.

Returning to the bug report (
https://osgeo-org.atlassian.net/browse/GEOT-5258) is not much help as it is
also expressed in terms of the solution (ie this XDate marker class).

Near as I can tell the point of this exercise is to provide a mapping for
bigdate:

    mappings.put("bigdate", XDate.class);

Client code is expecting to map "date" and "bigdate" to the java Date class
- but our JDBCDataStore provides a one-to-one mapping between datatype and
class:
- option: Introduce XDate, and allow client code to see XDate in the
resulting FeatureType
- option: Change the one-to-one mapping so that both "date" and "bigdate"
can map to Date
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to