A little more digging on this...
Down in com.webobjects.jdbcadaptor._FrontBasePlugin class, if I comment out
line 1825 in the formatValueForAttribute function (as shown below) , I am able
to save the Timestamp value in the database, so it looks like Frontbase doesn't
like the way this function is formatting he timezone part of a Timestamp value.
case FrontBaseTypes.FB_TimestampTZ: {
StringBuffer time = new
StringBuffer("TIMESTAMP '");
Date d =
(Date)eoattribute.adaptorValueByConvertingAttributeValue(obj);
SimpleDateFormat formatter =
TIMESTAMP_FORMATTER.get();
formatter.format(d, time, new
FieldPosition(0));
//
time.append(getTimeZone(formatter.getTimeZone()));
time.append('\'');
return time.toString();
}
Jeff
> On Jan 8, 2015, at 2:44 PM, Jeffrey Schmitz <[email protected]> wrote:
>
> Samuel, Ramsey,
>
> Hi All,
> I’m using Frontbase, and an EOObject with a field defined with the
> Prototype jodaLocalDateTime has stopped working. Since I recently updated my
> Wonder frameworks I suspect that has something to do with it.
>
> Looking at the SLQ produced for an INSERT on a machine still running the
> older Wonder frameworks, and that still works, the format of the time field
> is specified as: TIMESTAMP '2015-01-08 13:00:00.000’
>
> Looking at the SQL produced using the new Wonder Frameworks, the same field
> in the INSERT is specified as: TIMESTAMP '2015-01-08 00:54:42.847+00:00’
>
> I’m using the java datatype of org.joda.time.LocalDateTime
>
> Could your last change described in this email chain have affected this, as I
> don't think I rolled it in until now?
>
> Here's the full INSERT commands being generated...
>
> Works with older Wonder frameowrks:
> "INSERT INTO "t_event"("c_display", "c_title", "c_game", "id", "c_tv",
> "poolID", "c_all_day", "c_date_time", "c_description", "c_location",
> "c_group") VALUES ('true', 'test joda time', NULL, 1000073, NULL, 1000099,
> 'false', TIMESTAMP '2015-01-08 13:00:00.000', 'abcde', 'bed', NULL)"
> withBindings: >
>
> Does not work new Wonder frameworks:
> INSERT INTO 't_event'('c_display', 'c_tv', 'c_date_time', 'entryID',
> 'c_location', 'c_game', 'c_all_day', 'poolID', 'c_title', 'id',
> 'c_description', 'c_group') VALUES ('false', NULL, TIMESTAMP '2015-01-08
> 00:54:42.847+00:00', 1000002, 'TBA', 0, 'false', 1000001, 'NCAA BBall Round 1
> Game', 1000001, NULL, 0)" withBindings: >:
>
> Full Exception:
>
> INFO er.transaction.adaptor.Exceptions - Database Exception occured:
> com.webobjects.eoaccess.EOGeneralAdaptorException: EvaluateExpression failed:
> <com.webobjects.jdbcadaptor._FrontBasePlugIn$FrontbaseExpression: "INSERT
> INTO "t_event"("c_display", "c_tv", "c_date_time", "entryID", "c_location",
> "c_game", "c_all_day", "poolID", "c_title", "id", "c_description", "c_group")
> VALUES ('false', NULL, TIMESTAMP '2015-01-08 20:36:31.878+00:00', 1000002,
> 'TBA', 0, 'false', 1000001, 'NCAA BBall Round 1 Game', 1000001, NULL, 0)"
> withBindings: >:
> Next exception:SQL State:00000 -- error code: 231 -- msg: Semantic error
> 231. INSERT value doesn't match column: c_date_time.
> Next exception:SQL State:00000 -- error code: 485 -- msg: Semantic error
> 485. Near: INSERT INTO
> \"t_event\"(\"c_display\",\"c_tv\",\"c_date_time\",\"entryID\",\"c_location\",\"c_game\",\"c_all_day\",\"poolID\",\"c_title\",\"id\",\"c_description\",\"c_group\")
> VALUES('false',NULL,TIMESTAMP '2015-01-08
> 20:36:31.878+00:00',1000002,'TBA',0,'false',1000001,'NCAA BBall Round 1
> Game',1000001,NULL,0);.
> Next exception:SQL State:00000 -- error code: 485 -- msg: Semantic error
> 485. Near: 0.
> Next exception:SQL State:40000 -- error code: 363 -- msg: Exception
> condition 363. Transaction rollback.
>
>
>> On Nov 21, 2013, at 3:58 PM, Samuel Pelletier <[email protected]> wrote:
>>
>> Ramsey,
>>
>> My tests with different databases (mySql, PostgreSql and FrontBase) are now
>> all OK. I inserted and read back data with the 4 types with different time
>> zone on my machine successfully. I needed to make sure the data was saved in
>> an expected way for compatibility with others users of the data.
>>
>> This experience produced another pull request for FrontBase prototypes as
>> FrontBase TIME and TIMESTAMP types are not behaving like the one in MySql
>> and PostgreSql. I think Oracle does the same as PostgreSql. This difference
>> was a nightmare before I saw it because I was fixing for a system to break
>> another.
>>
>> I will look at the unit test later. I never touched them before, I need to
>> understand how they works.
>>
>> I also created a pull request to update JodaTime to version 2.3.
>>
>> Samuel
>>
>> Le 2013-11-21 à 15:09, Ramsey Gurley <[email protected]> a écrit :
>>
>>>
>>> On Nov 21, 2013, at 10:02 AM, Samuel Pelletier <[email protected]> wrote:
>>>
>>>> Ramsey,
>>>>
>>>> The current code in the master branch is broken for LocalTime AND
>>>> LocalDateTime unless your current time zone is GMT.
>>>
>>> I think it’s broken for GMT too on both of those.
>>>
>>>> I do not think the code should depend on the current application server
>>>> time zone.
>>>
>>> Correct, it should work no matter the time zone.
>>>
>>>> Here is my very simple test code.
>>>>
>>>> The good news is I think my current fix will not broke your data because I
>>>> convert back and from GMT. I want to test a complete run trip with other
>>>> database and change my computer time zone, actually, it works with
>>>> FrontBase.
>>>
>>> For your own testing that’s great. I’d leave the databases out of any unit
>>> tests though. You know the converters should produce the same value before
>>> and after, so just test that.
>>>
>>>>
>>>> BTW, Have you ever tried to compute airplane travel time based on the
>>>> local departure and arrival time?
>>>
>>> No, and I don’t envy anyone who has :D
>>>
>>>> I still have bad dreams about that… just find the airport time zone was
>>>> crazy at that time.
>>>>
>>>> Samuel
>>>>
>>>> LocalTime time1 = new LocalTime(12, 0, 0);
>>>> Date javaTime = ValueConversion.jodaLocalTime(time1);
>>>> LocalTime time2 = ValueFactory.jodaLocalTime(javaTime);
>>>> if (time1.equals(time2) == false) {
>>>> failed = true;
>>>> }
>>>>
>>>> LocalDate date1 = new LocalDate(2012, 1, 1);
>>>> Date javaDate = ValueConversion.jodaLocalDate(date1);
>>>> LocalDate date2 = ValueFactory.jodaLocalDate(javaDate);
>>>> if (date1.equals(date2) == false) {
>>>> failed = true;
>>>> }
>>>>
>>>> LocalDateTime localDateTime1 = new LocalDateTime(2012, 1, 1,
>>>> 12, 0, 0);
>>>> Date javaLocalDateTime =
>>>> ValueConversion.jodaLocalDateTime(localDateTime1);
>>>> LocalDateTime localDateTime2 =
>>>> ValueFactory.jodaLocalDateTime(javaLocalDateTime);
>>>> if (localDateTime1.equals(localDateTime2) == false) {
>>>> failed = true;
>>>> }
>>>>
>>>> DateTime dateTime1 = new DateTime(2012, 1, 1, 12, 0, 0);
>>>> Date javaDateTime = ValueConversion.jodaDateTime(dateTime1);
>>>> DateTime dateTime2 = ValueFactory.jodaDateTime(javaDateTime);
>>>> if (dateTime1.equals(dateTime2) == false) {
>>>> failed = true;
>>>> }
>>>>
>>>>
>>>> Le 2013-11-19 à 21:43, Ramsey Gurley <[email protected]> a écrit :
>>>>
>>>>>
>>>>> On Nov 19, 2013, at 12:12 PM, Samuel Pelletier <[email protected]> wrote:
>>>>>
>>>>>> The code in ValueFactory.java does nothing, a simple return new
>>>>>> LocalDateTime(value) does the same thing.
>>>>>>
>>>>>> The problem with the LocalDateTime is the SQL timestamp is by definition
>>>>>> an absolute point in time and that means it's calendar representation is
>>>>>> time zone dependant.
>>>>>>
>>>>>> I think the LocalDate and LocalTime can work with my fix
>>>>>
>>>>> LocalDate and DateTime works based on a modification of the test code I
>>>>> attached. Value in == value out. Feel free to simplify it if the Calendar
>>>>> stuff is not required. Just don’t break it :-) I use those two.
>>>>>
>>>>>> but for LocalDateTime, I would need to add a double time zone adjustment
>>>>>> to UTC or GMT; convert to UTC on save and from UTC on read.
>>>>>>
>>>>>> LocalDate and LocalTime seems more easily handled but I need to test.
>>>>>>
>>>>>> I try to avoid timestamp except for usage like log entry timestamp where
>>>>>> we want to know when something occurred. For local time, I prefer string
>>>>>> columns, their behaviour is always predictable.
>>>>>>
>>>>>> Samuel
>>>>>
>>>>> I hate strings that need to conform to a certain format. It never fails.
>>>>> Someone always inserts something poorly formatted or a F'in magic string
>>>>> in the column.
>>>>>
>>>>> is_active
>>>>> “TRUE”
>>>>> “FALSE”
>>>>> “F”
>>>>> “YES"
>>>>> “MAYBE”
>>>>>
>>>>> happy_hour
>>>>> “18:00:00”
>>>>> “99:99:99”
>>>>> “noon"
>>>>> “Gerald”
>>>>> “CUSTOM"
>>>>>
>>>>> I prefer to use the correct value type for the value being stored.
>>>>> Correct value types prevent all sorts of clever tricks. You see that
>>>>> preference of mine reflected in the existing prototypes. For postgres at
>>>>> least, the external types are the correct ones for the datastore.
>>>>> LocalTime uses time. LocalDate uses date. LocalDateTime and DateTime use
>>>>> timestamp. For other DBs, IDGAF so much :-)
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/jeff%40netbrackets.com
>>
>> This email sent to [email protected]
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/jeff%40netbrackets.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
