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]
>>
>>
>>
>
>
> 


Reply via email to