Yes Kapser, I made the changes, mentioned by you and it is working in my machine as well. I am fine with the patch updates so +1 for my side for the fix.
Thanks, Balendra On 07/08/2013, Kasper Sørensen <[email protected]> wrote: > Hmm seems this is caused because of a time zone conflict in the call > to DateUtils.get(year,month,date) ... > > If you replace > > cal.setTime(DateUtils.get(2013, Month.JANUARY, 23)); > cal.setTimeZone(TimeZone.getTimeZone("GMT+1")); > > with this: > > cal.setTimeZone(TimeZone.getTimeZone("GMT+1")); > cal.setTimeInMillis(0); > cal.set(Calendar.HOUR, 0); > cal.set(Calendar.MINUTE, 0); > cal.set(Calendar.SECOND, 0); > cal.set(Calendar.MILLISECOND, 0); > cal.set(Calendar.HOUR, 0); > cal.set(Calendar.MINUTE, 0); > cal.set(Calendar.YEAR, 2013); > cal.set(Calendar.MONTH, Calendar.JANUARY); > cal.set(Calendar.DAY_OF_MONTH, 23); > > Then I believe it works, right? (At least did for me if I changed my > machines time zone). > > Java date handling, sigh :-( > > 2013/8/7 Balendra Singh <[email protected]>: >> Kasper, >> >> I agree with your updates on the patch.I have a doubt regarding the >> SalesforceDataContextTest.testRewriteWhereItem. This test is failing as >> time returned is something different from the assert value. Thats why I >> had >> to update the assert values in updated patch. >> Please provide your inputs on this. >> >> >> Thanks, >> Balendra >> >> >> On 7 August 2013 15:06, Kasper Sørensen >> <[email protected]>wrote: >> >>> I checked the updated patch and it looks good. I did make a few minor >>> changes, the primary one is to check against the ColumnType in the >>> rewriteFilterItem(...) method, instead of checking against the operand >>> type. The reason is that a java.util.Date can be passed as both a DATE >>> or as a TIMESTAMP value. Even as a TIME value. So the evaluation of >>> which date format to use should be on the basis of the column metadata >>> instead of the object that is passed in by the user. >>> >>> Uploaded the patch with my additions to JIRA as well. Please let me >>> know if you agree to the adjustments. >>> >>> 2013/8/7 Balendra Singh <[email protected]>: >>> > Hi Kasper, >>> > >>> > * In SalesforceDataSet, replaced tabs by spaces. >>> > * In the test SalesforceDataContextTest.testRewriteWhereItem - I >>> > changed >>> > the timezone to previous GMT+1 but with this also, it was failing so I >>> had >>> > to change dateTime value to *2013-01-22T18:30:00+0000.* >>> > Added the updated patch on the issue. >>> > Please provide your inputs. >>> > >>> > >>> > Thanks, >>> > Balendra >>> > * >>> > * >>> > * >>> > * >>> > >>> > >>> > On 7 August 2013 12:56, Kasper Sørensen >>> > <[email protected] >>> >wrote: >>> > >>> >> Sorry for the late reply Balendra, I just now realized the new JIRA >>> >> ticket with the patch [1]. >>> >> >>> >> I looked at the patch and it looks good except for two small doubts >>> >> from my side: >>> >> >>> >> * In the SalesforceDataSet all the spaces have been replaced by >>> >> tabs. >>> >> We do use spaces in MM, and changing it makes it harder to see the >>> >> diff. >>> >> * In the test SalesforceDataContextTest.testRewriteWhereItem you've >>> >> changed the example input timezone from GMT+1 to UTC. Is there a >>> >> reason for this? I see you also changed the subsequent assertions, >>> >> but >>> >> I doubt why this was necesary at all? >>> >> >>> >> If you can maybe fix/answer these points, then I am good to give it >>> >> my >>> +1. >>> >> >>> >> And a remark for everyone: The patch is made against the org.eobjects >>> >> codebase. Obviously we will apply it to both codebases. Since this is >>> >> a bugfix, I imagine it will also go into a bugfix release of the old >>> >> MetaModel. >>> >> >>> >> [1] https://issues.apache.org/jira/browse/METAMODEL-9 >>> >> >>> >> 2013/8/2 Kasper Sørensen <[email protected]>: >>> >> > Hi Balendra, >>> >> > >>> >> > Is it possible for you to post it as a patch file. Either upload it >>> >> > to >>> >> > the MM JIRA [1] or simply make a gist [2] or so. >>> >> > >>> >> > [1] https://issues.apache.org/jira/browse/METAMODEL >>> >> > [2] https://gist.github.com/ >>> >> > >>> >> > 2013/8/2 Balendra Singh <[email protected]>: >>> >> >> Hi, >>> >> >> >>> >> >> In my case field type is date. SalesforceTable is returning >>> >> ColumnType.DATE >>> >> >> for date, datetime and time. In SalesforceDataSet, it is using a >>> >> datetime >>> >> >> format to format my date value field and was throwing exception. >>> >> >> >>> >> >> I made the following fixes for this issue - >>> >> >> >>> >> >> 1. In SalesforceDataSet.convert(Object value, ColumnType >>> >> >> columnType) >>> >> >> >>> >> >> private Object convert(Object value, ColumnType columnType) { >>> >> >> if (value instanceof String && !columnType.isLiteral()) { >>> >> >> if (columnType.isBoolean()) { >>> >> >> return BooleanComparator.toBoolean(value); >>> >> >> } >>> >> >> if (columnType.isNumber()) { >>> >> >> return NumberComparator.toNumber(columnType.isNumber()); >>> >> >> } >>> >> >> if (columnType.isTimeBased()) { >>> >> >> >>> >> >> SimpleDateFormat format; >>> >> >> *if (columnType == ColumnType.DATE) {* >>> >> >> * >>> >> >> * >>> >> >> * format = new SimpleDateFormat(* >>> >> >> * SalesforceDataContext.SOQL_DATE_FORMAT_IN);* >>> >> >> * } else if (columnType == ColumnType.TIMESTAMP) {* >>> >> >> * format = new SimpleDateFormat(* >>> >> >> * SalesforceDataContext.SOQL_DATE_TIME_FORMAT_IN);* >>> >> >> * } else {* >>> >> >> * format = new SimpleDateFormat(* >>> >> >> * SalesforceDataContext.SOQL_TIME_FORMAT_IN);* >>> >> >> * }* >>> >> >> format.setTimeZone(SalesforceDataContext.SOQL_TIMEZONE); >>> >> >> try { >>> >> >> return format.parse(value.toString()); >>> >> >> } catch (ParseException e) { >>> >> >> throw new IllegalStateException( >>> >> >> "Unable to parse date/time value: " + value); >>> >> >> } >>> >> >> } >>> >> >> } >>> >> >> return value; >>> >> >> } >>> >> >> >>> >> >> >>> >> >> 2. In SalesforceDataContext added the following date format strings >>> >> >> - >>> >> >> >>> >> >> public static final String SOQL_DATE_FORMAT_IN = "yyyy-MM-dd"; >>> >> >> public static final String SOQL_DATE_FORMAT_OUT = >>> >> >> "yyyy-MM-dd"; >>> >> >> public static final String SOQL_DATE_TIME_FORMAT_IN = >>> >> >> "yyyy-MM-dd'T'HH:mm:ss.SSS"; >>> >> >> public static final String SOQL_DATE_TIME_FORMAT_OUT = >>> >> >> "yyyy-MM-dd'T'HH:mm:ssZZZ"; >>> >> >> public static final String SOQL_TIME_FORMAT_IN = >>> >> >> "HH:mm:ss.SSS"; >>> >> >> public static final String SOQL_TIME_FORMAT_OUT = >>> >> >> "HH:mm:ssZZZ"; >>> >> >> >>> >> >> 3. In SalesforceTable.toColumnType - I have returned specific date >>> >> >> datatypes >>> >> >> >>> >> >> >>> >> >> protected static ColumnType toColumnType(FieldType type) { >>> >> >> switch (type) { >>> >> >> case _boolean: >>> >> >> return ColumnType.BOOLEAN; >>> >> >> case _int: >>> >> >> return ColumnType.INTEGER; >>> >> >> case _double: >>> >> >> return ColumnType.DOUBLE; >>> >> >> * case date:* >>> >> >> * return ColumnType.DATE;* >>> >> >> * case datetime:* >>> >> >> * return ColumnType.TIMESTAMP;* >>> >> >> * case time:* >>> >> >> * return ColumnType.TIME;* >>> >> >> case string: >>> >> >> case email: >>> >> >> case url: >>> >> >> case phone: >>> >> >> case reference: >>> >> >> case textarea: >>> >> >> case encryptedstring: >>> >> >> case base64: >>> >> >> case currency: >>> >> >> case id: >>> >> >> case picklist: >>> >> >> return ColumnType.VARCHAR; >>> >> >> } >>> >> >> return ColumnType.OTHER; >>> >> >> } >>> >> >> >>> >> >> Please validate the code changes for the issue. >>> >> >> >>> >> >> >>> >> >> Thanks, >>> >> >> Balendra >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> On 1 August 2013 18:41, Kasper Sørensen < >>> [email protected] >>> >> >wrote: >>> >> >> >>> >> >>> Strange, it seems that Salesforce sends dates back in not just a >>> >> >>> single, but various formats. Usually we have seen the format >>> >> >>> "yyyy-MM-dd'T'HH:mm:ss.SSS" (Represented by >>> >> >>> SalesforceDataContext.SOQL_DATE_FORMAT_IN). In your case it seems >>> >> >>> it >>> >> >>> simply sent a date in the format yyyy-MM-dd. Do you happen to >>> >> >>> know >>> >> >>> what field this failed for, and what datatype it had? Maybe this >>> >> >>> is >>> a >>> >> >>> simple case that we need to distinguish in a more detailed manner >>> for >>> >> >>> e.g. DATE vs DATETIME vs TIMESTAMP types... >>> >> >>> >>> >> >>> Anyways, the fix shouldn't be too hard. Simplest solution would >>> >> >>> be >>> to >>> >> >>> simply make a "convertToDate(String)" method in SalesforceUtils >>> >> >>> and >>> >> >>> probe the incoming string to select a proper date format. >>> >> >>> >>> >> >>> 2013/8/1 Balendra Singh <[email protected]>: >>> >> >>> > While using metamodel in our project we found the following >>> >> exception - >>> >> >>> > >>> >> >>> > In salesforce, if date value is provided then >>> >> >>> > SalesforceDataSet<http://eobjects.org/trac/wiki/SalesforceDataSet >>> > >>> >> is >>> >> >>> > throwing following exception while inserting this record to >>> >> >>> > some >>> >> other >>> >> >>> > database. >>> >> >>> > >>> >> >>> > *Stacktrace* >>> >> >>> > >>> >> >>> > Job execution FAILURE - Unable to parse date/time value: >>> 2012-08-02 ( >>> >> >>> > IllegalStateException < >>> >> >>> http://eobjects.org/trac/wiki/IllegalStateException>) >>> >> >>> > - Exception stacktrace of failure condition: >>> >> >>> > java.lang.IllegalStateException< >>> >> >>> http://eobjects.org/trac/wiki/IllegalStateException>: >>> >> >>> > Unable to parse date/time value: 2012-08-02 at >>> >> >>> > org.eobjects.metamodel.salesforce.SalesforceDataSet< >>> >> >>> http://eobjects.org/trac/wiki/SalesforceDataSet>. >>> >> >>> > convert(SalesforceDataSet >>> >> >>> > <http://eobjects.org/trac/wiki/SalesforceDataSet>.java:119) >>> >> >>> > at org.eobjects.metamodel.salesforce.SalesforceDataSet< >>> >> >>> http://eobjects.org/trac/wiki/SalesforceDataSet> >>> >> >>> > .getRow(SalesforceDataSet >>> >> >>> > <http://eobjects.org/trac/wiki/SalesforceDataSet>.java:98) >>> >> >>> > at org.eobjects.analyzer.job.runner. >>> >> >>> > RowProcessingPublisher< >>> >> >>> http://eobjects.org/trac/wiki/RowProcessingPublisher> >>> >> >>> > .processRows(RowProcessingPublisher< >>> >> >>> http://eobjects.org/trac/wiki/RowProcessingPublisher>.java:295) >>> >> >>> > at >>> >> >>> > org.eobjects.analyzer.job.tasks.RunRowProcessingPublisherTask?< >>> >> >>> http://eobjects.org/trac/wiki/RunRowProcessingPublisherTask> >>> >> >>> > .execute(RunRowProcessingPublisherTask?< >>> >> >>> http://eobjects.org/trac/wiki/RunRowProcessingPublisherTask> >>> >> >>> > .java:43) >>> >> >>> > >>> >> >>> > at org.eobjects.analyzer.job.concurrent.TaskRunnable< >>> >> >>> http://eobjects.org/trac/wiki/TaskRunnable> >>> >> >>> > .run(TaskRunnable <http://eobjects.org/trac/wiki/TaskRunnable >>> >> >.java:63) >>> >> >>> at >>> >> >>> > java.util.concurrent.ThreadPoolExecutor< >>> >> >>> http://eobjects.org/trac/wiki/ThreadPoolExecutor> >>> >> >>> > $Worker.runTask(ThreadPoolExecutor< >>> >> >>> http://eobjects.org/trac/wiki/ThreadPoolExecutor>.java:886) >>> >> >>> > at java.util.concurrent.ThreadPoolExecutor< >>> >> >>> http://eobjects.org/trac/wiki/ThreadPoolExecutor> >>> >> >>> > $Worker.run(ThreadPoolExecutor?< >>> >> >>> http://eobjects.org/trac/wiki/ThreadPoolExecutor>.java:908) >>> >> >>> > at java.lang.Thread.run(Thread.java:662) >>> >> >>> >>> >> >>> >
