could you add that as a note on the Oracle JDBC datastore page -
https://github.com/geotools/geotools/blob/master/docs/user/library/jdbc/oracle.rst
to help others out in the future
Cheers
Ian
On 12 May 2017 at 09:23, Walter Stovall <walter.stov...@byers.com> wrote:
> My problem is resolved by using the following JVM flag:
>
>
>
> -Doracle.jdbc.mapDateToTimestamp=false
>
>
>
> This restores the legacy mapping of DATE to sqlType 91 instead of 93 and
> as a result GeoTools will not expect time to be supplied with date and will
> not output time when writing a date as a string.
>
>
>
> *From:* andrea.a...@gmail.com [mailto:andrea.a...@gmail.com] *On Behalf
> Of *Andrea Aime
> *Sent:* Wednesday, May 10, 2017 12:23 PM
> *To:* Walter Stovall <walter.stov...@byers.com>
> *Cc:* geoserver-devel@lists.sourceforge.net
> *Subject:* Re: [Geoserver-devel] Oracle DATE treated as TIMESTAMP makes
> WFS handle the value incorrectly when using a VTABLE
>
>
>
> On Wed, May 10, 2017 at 6:15 PM, Walter Stovall <walter.stov...@byers.com>
> wrote:
>
> fwiw this looks more like a problem with the Oracle driver than GeoTools.
> The sqlType=93 is Timestamp as represented by the ResultSetMetadata but it
> seems like it should be sqlType=91 (Date). I’m looking at how to make
> GeoTools handle a work around for this Oracle issue.
>
>
>
> Yes, if you check the archives of geotools/geoserver there has already
> been a discussion about it, but
>
> not resolution (usual stuff, when a commercial component is in the mix
> like Oracle, only paid support
>
> is active, nobody is going to move a finger in their spare time for it).
>
>
>
> When you have a solution do a pull request following the GeoTools
> contribution rules:
>
> https://github.com/geotools/geotools/blob/master/CONTRIBUTING.md
>
> (in short, add a test, make sure your added code is properly formatted but
> don't reformat
>
> code you did not modify).
>
>
>
> Cheers
>
> Andrea
>
>
>
>
>
> --
>
> ==
>
> GeoServer Professional Services from the experts! Visit
>
> http://goo.gl/it488V for more information.
>
> ==
>
>
>
> Ing. Andrea Aime
>
> @geowolf
>
> Technical Lead
>
>
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054 Massarosa (LU)
>
> phone: +39 0584 962313 <+39%200584%20962313>
>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
>
> mob: +39 339 8844549 <+39%20339%20884%204549>
>
>
>
> http://www.geo-solutions.it
>
> http://twitter.com/geosolutions_it
>
>
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
>
>
> -------------------------------------------------------
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
Ian Turton
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
