The important thing to remember about Timestamps is that they are like constants - a Timestamp
represents a specific moment in time regardless of where the user is. Developers get confused and
think they have to "adjust" Timestamps - something you can't do. However, you CAN adjust how the
Timestamp is displayed - to present the moment in time in the user's time zone.
If I create a record at 5pm my time (PST) and at the exact same time someone on the east coast
creates a record (8 pm their time) - both records will have the same Timestamp value. If they
aren't, then that's a bug - something went wrong in converting the user's time zone to a Timestamp.
-Adrian
Vince M. Clark wrote:
If in fact timestamps are causing problems it seems to me that a simple fix would be to write the records to the target with the current time on the target rather than inheriting timestamps from the source.
----- Original Message -----
From: "Vince M. Clark" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, December 7, 2007 11:13:16 AM (GMT-0700) America/Denver
Subject: Re: Strange behavior with Entity Sync
Clarification. The timestamps on the central server are GMT. POS terminals are all in their local timezones. So we do get into a bit of trickiness around timestamps I think.
Here is the summary of what I'm doing:
To setup the pull I create an entity sync record on the source (MCS)
I load the recurrence rule and job on the target (POS)
The pull launches, and sucks everything down from the server based on the EntityGroup defined on the MCS. During this process it appears as though the records are written to POS with the server timestamp. The sync process does not seem to change the timestamp to the local time on the POS terminal. This seems to be OK for data that is only pulled, because the next job that runs a pull will depend on logic running on MCS to determine what records to send down to POS.
But then when we trigger the push, some entities are synched both ways, such as inventory.
We did have one situation where inventory was overwritten on MCS with bad data. My theory is that the POS terminal pulled that data from the server initially with the server timestamp. Then on the push, since the server timestamp was in the future, the push process picked up those records as having been changed.
This might explain why our initiial push takes forever. The pos terminals may be sending everything back to the server.
I'll try setting all machines to the same timezone and see if it stabilizes the process.
----- Original Message -----
From: "David E Jones" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, December 7, 2007 10:57:34 AM (GMT-0700) America/Denver
Subject: Re: Strange behavior with Entity Sync
Yeah, it doesn't sound like it's a time zone problem. As long at the
timestamps in the databases are all GMT then it shouldn't be a bit deal.
There could be other things going on though, like the last updated
stamp for a certain record on the target server could be more recent
than the one on the source server (if seed/initial data was loaded on
the source and then on the target, even if the source was updated
before the target was loaded) then it would not write the record. Of
course, if that happens it will tell you that it did that and you'll
at least see it in the summary numbers that come back from the remote
call.
It sounds like you have things far enough along that the only way to
progress is with elbow grease. In other words pick a couple of records
that you think should be transfered over but that are not getting
copied, and then look at the data (on both source and target if
applicable) and read through the code to see exactly what it would do
with that data.
-David
On Dec 7, 2007, at 10:27 AM, Vince M. Clark wrote:
I don't know for sure that we are dealing with a timezone issue.
That is just one theory as we try to iron out some problems with
entity sync. The fact that the same records always seem to be
problematic gives us a pattern to pursue. I'll update the thread as
we research the problem.
----- Original Message -----
From: "Adrian Crum" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, December 7, 2007 10:33:19 AM (GMT-0700) America/Denver
Subject: Re: Strange behavior with Entity Sync
I don't know if the recent time zone work would have any affect on
this. It's a possibility.
I'm not familiar with POS and entity sync, so I'll describe the
changes I made and maybe others who
are more familiar with Vince's setup can figure it out.
The basic concept is:
1. Date/time String in UI (user's time zone) gets converted to
TimeStamp (which is referenced to
GMT), then it is stored.
2. TimeStamp in storage (GMT) gets converted to date/time String for
UI (user's time zone).
3. Only the screen widget and Freemarker template code was changed.
You shouldn't have to set all of your terminals to the same time
zone as the server. If the problem
is in OFBiz, we should fix it.
-Adrian
Vince M. Clark wrote:
Yes. I pulled it from trunk about a week ago.
----- Original Message -----
From: "Jacopo Cappellato" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, December 7, 2007 8:36:18 AM (GMT-0700) America/Denver
Subject: Re: Strange behavior with Entity Sync
Hi Vince,
are you running a recent OFBiz revision?
I guess that Scott asked you about the timezones because we have
recently refactored the way datetimes are treated in OFBiz: Adrian
Crum
worked on this, and he could better explain, but the idea is that
when a
date field is edited it is converted from the user session locale
to the
system locale.
I think that Scott could be right... Adrian, do you think that your
work
could have caused some side effects on the entity synch stuff?
Jacopo
Vince M. Clark wrote:
It could be a timezone issue. We will test a bit more and try to
nail down a pattern. We can isolate the problem to the same set of
records that always get pulled incomplete.
The server is set to GMT and all the POS terminals are mountain.
When first setting up sync I had some difficulty getting the PULL
to start running and suspected it was due to the timezone being in
the future on the server. But we got past that.
Given that we will have terminals in all US timezones it is not
really a good option to set them all to the same time as the server.
----- Original Message -----
From: "Scott Gray" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, December 6, 2007 11:32:11 PM (GMT-0700) America/
Denver
Subject: Re: Strange behavior with Entity Sync
Just a stab in the dark but do these issues arise if the server
and terminal
are in the same timezone?
Regards
Scott
On 07/12/2007, Vince M. Clark <[EMAIL PROTECTED]> wrote:
BJ - your question is not ignorant, but I have no idea how to
answer.
We'll have to depend on others in the community much smarter than
us.
Entity Sync is a feature available in the system. We are using it
and I
can only assume that it works if configured properly. I have
figured out the
basics of push and pull synchronization. That is about as much
intelligence
as I can claim.
I can get into the details of what I loaded and where if
necessary, such
as EnityGroup, EnittySync, RecurrenceRule, etc.
----- Original Message -----
From: "BJ Freeman" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, December 6, 2007 4:35:09 PM (GMT-0700) America/
Denver
Subject: Re: Strange behavior with Entity Sync
ignorant question
does not entity sync mess up the accounting.
how are the ecas that are suppose to fire based on certain
services,
that do CRUD of the entity suppose to fire?
am I missing some documentation on how this works?
Vince M. Clark sent the following on 12/6/2007 1:58 PM:
We are using entity sync to keep POS terminals and a central
server
synchronized. We are going direct from POS to MCS, no Per Store
Server
involved. We have a pull sync (MCS to POS) and a push sync (POS
to MCS.)
Some data such as inventory is going both ways.
A few issues:
1) Records deleted on MCS are not deleted on POS.
2) Pull sync is not getting complete records in some cases. Two
entities
we see this consistenly is on Facility and InventoryItem. We get
partial
records sometimes. Note that this only seems to occur on the
initial pull
when we are first populating a new POS terminal from the central
server.
Once we identify a record, such as a facility, that didn't come
down
completely we can update the timestamp on the server and the next
pull gets
the complete record.
3) Related to item 2. If a push occurs from the POS terminal
BEFORE we
get the initial data correct, it overwrites the data on MCS. For
example, if
a facility record was pulled down and the store id is missing
then when the
terminal push occurs it trashes the facility record on the
server. Strange
thing is we aren't pushing facility data, only pulling.
Note that the server time is different than the terminals
(different
timezones.)
Vince Clark
Global Era
The Freedom of Open Source
[EMAIL PROTECTED]
(303) 493-6723
