I thought about that, but when I did a new Migrate, the generated code was no
different than what it previously was, e.g.
eventTable.newTimestampColumn("c_date_time", false);
However, maybe I need to update the EOGenerator in some way? If so, I'm not
sure where I would go to download the latest or exactly what I would need to
download? A new WOLips version? A new template?
Looking at the latest ERXMigrationTable class in wonder, I don't see any
functions like newTimestampWithTZColumn that might fit the bill.
Thanks,
Jeff
> On Jan 9, 2015, at 2:05 AM, Johann Werner <[email protected]> wrote:
>
> Hi Jeff,
>
> I can remember that there was a fix for FrontBase prototypes some time ago. A
> search within the commit messages reveals a commit from Samuel dating back to
> 21.11.2013 where the prototype was changed from TIMESTAMP to TIMESTAMP WITH
> TIME ZONE. What type are your table columns in FrontBase? Could it be that
> they are still expecting a TIMESTAMP without timezone and thus stumbling
> across your value? So a fix would probably be a migration that changes your
> „old“ joda columns to the new value type.
>
> You can read the conversation about that change at github to get a little
> more detail: https://github.com/wocommunity/wonder/pull/512
>
> HTH
> jw
>
>
>> Am 09.01.2015 um 04:02 schrieb Jeffrey Schmitz <[email protected]>:
>>
>> 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]
