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/archive%40mail-archive.com
This email sent to [email protected]
