On 6/17/2010 9:42 AM, Adam Heath wrote:
Adrian Crum wrote:
On 6/17/2010 9:09 AM, Adam Heath wrote:
The seed data works fine. It has been working fine for years. It's the
process you're using that is the problem.
Also, if my process is wrong, fine, that might be true. But just
don't tell me it is wrong. Give me a way to do what I have describe
countless times.
I believe the reason for some of the confusion lies in the subject being
a moving target, or different subjects being blurred together. It might
help to make some clear distinctions:
1. Existing, out-of-the-box seed data works as expected. Date-time
values in the seed data are referenced to the server's time zone and
that data displays as intended or expected. Out-of-the-box seed data is
not broken - it has been working fine for years.
2. Entity data in XML format that contains date-time data will cause
problems if it is shared by servers in different time zones. The reason
is because no time zone is specified in the XML file, so each server
will reference date-time values to its own time zone. We need a way to
specify a time zone in the XML data so that each server will reference
the same time zone when importing the data.
3. Developers who wish to share entity data in XML format between
servers in different time zones will need to define a process that
specifies a time zone to be shared, and then ensure the shared XML data
contains the specified time zone. In other words, the specified time
zone is an anchor or key - all shared XML data uses that time zone.
To summarize what I've been saying:
1. You have identified a problem in sharing XML data that contains
date-time values and I agree it needs to be fixed. I suggest we specify
a time zone in the XML files, and if no time zone is specified, the
server's time zone is used.
2. The existing, out-of-the-box seed data files work fine. Please do not
specify time zones in the existing seed data files because that will
break a lot of existing code.
This is wrong. Existing seed data *is* broken.
user_login_id | group_id | from_date | thru_date |
last_updated_stamp | last_updated_tx_stamp |
created_stamp | created_tx_stamp
---------------+-----------+------------------------+-----------+----------------------------+----------------------------+----------------------------+----------------------------
system | FULLADMIN | 2001-01-01 13:00:00-05 | |
2010-06-13 22:25:38.727-04 | 2010-06-13 22:25:38.664-04 | 2010-06-13
22:25:38.727-04 | 2010-06-13 22:25:38.664-04
system | FULLADMIN | 2001-01-01 12:00:00-05 | |
2010-06-15 20:30:20.83-04 | 2010-06-15 20:30:20.723-04 | 2010-06-15
20:30:20.83-04 | 2010-06-15 20:30:20.723-04
(3 rows)
This is output from psql, of UserLoginSecurityGroup. Note the 1 hour
difference on the fromDate. On 06-13, I imported all seed xml in
ofbiz on a machine in CDT. I then did a pg_dump, copied the file to a
machine in EDT, imported it. Then, did *just* a seed import on the
new machine. No seed data was actually changed. I now have duplicate
records.
See #3 above.
3. If you follow my suggestions and you're still having problems, then
there is something wrong in the process you're using.
I'm not trying to be argumentative or aloof - I'm really trying to help.
I just don't know how to make it any simpler.
-Adrian
