One question: in case of crash (be the net, the server or a POS - power outage for instance) should the
resetEntitySyncStatusToNotStarted service be run only from the server? Is it enough?
Because most of the time, in my case, the problem comes from the net and unfortunately my client uses an IBM POS system which needs
IBM jdk for the POS to run. But (without tweaks?) the IBM jdk is not able to run OFBiz in standard mode. So I can't use
startofbizboth to have concurrently webtools and the POS GUI.
Hope it's clear
Jacques
From: "Jacques Le Roux" <[email protected]>
I have opened https://issues.apache.org/jira/browse/OFBIZ-3333 (what a number,
though 333 is more symbolic :o)
More to come...
Jacques
From: "Marc Morin" <[email protected]>
Yes, i go in spurts on reading this group. I just thought I'd drop on note on an issue that I am starting to investigate. I
DIDN'T take the time (sorry) to read even a single email on the subject before posting. Imagine my embarrassment when I posted
right in the middle of a heavily discussed topic on the exact topic I was posting on. Apologies.
Anyway, just wanted to put out a request to see if others see value in this "merged" rows type of sync. Essentially a set of
content, a nest of rows (inter-related) are "published" from one instance and have multiple "slaves" for it. For the simpler
case where the entire contents of tables are published and the slaves are "readonly", there are a number of db-level technologies
that work very well for that,and I am not trying to replace/redo that case.
So for this publish/subscribe model, doing this within Ofbiz will maintain the db independence, which is good. Ideally, there
are three modes of updates: synchronous, asynchronous and batch. (Asynchronous and batch are very closely related and likely
implemented the same way). We only need the asynch/batch mode.
This could be done via:
1- eeca gathering up changes, published in master db as log, then send to slave
for reply.
2- time base (like current sync)
For our use case, either approach is fine, but since #2 is already in the entity-sync, we'd be leaning that way for now. Our
application space is such that all instances of our databases are available to all app servers via a separate delegator, so,
RMI/SOAP, and other issue about getting the change set from the master to slave application is much simplified.
Since we'd be merging rows from multiple masters into a single table, we configure the sequenced-id-prefix for each instance to
be different, generating unique ids.
Marc Morin
Emforium Group Inc.
ALL-IN Software™
519-772-6824 ext 201
[email protected]
----- Original Message -----
From: "Jacques Le Roux" <[email protected]>
To: [email protected]
Sent: Tuesday, October 27, 2009 1:35:48 PM GMT -05:00 US/Canada Eastern
Subject: Re: Entity Sync
Do you mean it was a simple error on your side (sorry I did not take the time
to read all yet ;o) ?
Jacques
From: "Marc Morin" <[email protected]>
Rookie error... apologies
----- Original Message -----
From: "Jacques Le Roux" <[email protected]>
To: [email protected]
Sent: Tuesday, October 27, 2009 9:36:50 AM GMT -05:00 US/Canada Eastern
Subject: Re: Entity Sync
Hi Marc,
Did you follow recent threads on this subject ?
Jacques
From: "Marc Morin" <[email protected]>
We have a couple of use cases where we need to sync a subset of the information
in one database and mirror it into another.
Been looking at the entity sync capability that is present in ofbiz. Very good
start, ability to build a sync set that is a
collection of entities to sync (pull or push) between delegators (or service).
In my case, I need to create the nest of entities to consider for the sync, but
I need to restrict the rows from some starting
point.
Use case 1: Want to import a collection of parties from one system along with their relationships between the set of parties
and
their contact info, notes, preferences, etc....
Use case 2: Create a product category, rollups, and then associate products to
that category. Want to publish this category,
products, and subset of pricing, product content, features, etc.... to other
instances.
Looks like a modification to entity sync is required to do this? or am i
mistaken.
Modification involves:
- build set of entities in sync group
- add condition restrictions on possibly any number of entities for candidate
rows. (category_id = 'x')
- "soft" inclusion by foreign key reference from a row in the set to one that
is not explicit.
- alter row for foreign key references outside of entity set to null or to rows
that cannot be replicated.
I'm sure more precision is needed here and will to do the work. Just wanted to
see if others have similar use cases and if so,
what they have done.
Marc Morin
Emforium Group Inc.
ALL-IN Software™
519-772-6824 ext 201
[email protected]
