BTW as it comes over and over, I will do a FAQ for that...
Jacques
From: "Jacques Le Roux" <[EMAIL PROTECTED]>
Just be curious ;o)
From
http://docs.ofbiz.org/download/attachments/4369/AdvancedFrameworkTranscription20060824.pdf
So unlike a package that each entity fits in one and only
one of the groups are a data structure, rather than a
configuration file we can use to group an arbitrary set of
entities. Each group will have an ID and a name. In
the entity reference pages we do see the timestamps
that the entity engine automatically maintains for all
entities, unless you use the attribute we talked about in
the entity definitions to turn it off. But by default all entities
will have these four fields; lastUpdatedStamp, lastUpdatedTxStamp
(transaction), createdStamp, and
createdTxStamp..
The transaction stamps are when the transaction was
begun that the change is part of, and the stamps are
within that transaction, although they are an absolute
value. But to order the actual records that changed
within the transaction.
Okay and the entity engine does do things for these
stamp fields when it maintains them, by the way, that
ensure that within a transaction each updated or created
stamp, depending on whether it's a create or updated,
is unique for that transaction.
So it'll keep track of the last one and always increment
it by one, even if it's been less than a millisecond since
the other record went through. As long as you don't
have more than a thousand records going into the database
per second in a single transaction then you
shouldn't have problems with overflowing it too much.
But it is important that those are unique, so we can
order all the records by these stamps and basically
reproduce the transaction to send it over to the other
server. Even reproducing the transaction we can't always
eliminate problems with foreign keys, but we'll talk
about that in a bit. Anyway that's the intention here, to
reduce problems with foreign keys as much as possible
and recreate the data changes on the remote server
when the synchronization goes through
Remember : OFBiz was well thought out ! Be confident...
Jacques
From: "Jacek Wagner" <[EMAIL PROTECTED]>
BJ Freeman wrote:
that is transaction, like in updating data.
BJ Freeman sent the following on 8/27/2008 2:52 PM:
TX stands for transaction
you will note the LAST_UPDATED_STAMP is different also before you run
the service
Jacek Wagner sent the following on 8/27/2008 2:39 PM:
What is a purpose for having two (2) last updated datetimes
(LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP). Every time I run a service
(any) those stamps are one or two seconds apart.
Curious Jacek
Can you present a case where only LAST_UPDATED_STAMP or
LAST_UPDATED_TX_STAMP will be updated.
