Sync Strategy for RMS: 'Received always beats Delivered'
Fran Boon
In RMS:
we have a Req status of 'Delivered' (which means that the Pledger
believes that the Requestor has the goods)
we have a Req status of 'Received' (which means that the Requestor
confirms that they have the goods)
I think this could use a Sync Strategy other than just 'Last status
wins', maybe:
'Received always beats Delivered unless set by Admin' <- this assumes
that the admin role is only used for data fixes, not for normal
activities.
Is this something that fits within the current Sync design?
Many thanks,
Fran.
Amer Tahir
I'm not sure if I understood what you're suggesting here. If you're
suggesting that a sync policy could favor particular field values, i.e
in this case "Received always beats Delivered unless set by Admin", I
don't think this is a good idea as it is tied to a particular module,
field and set of values. Sync should work on a more generic level,
shouldn't it?
> --
> You received this message because you are subscribed to the Google Groups "Sahana-Eden" group.
> To post to this group, send email to sahan...@googlegroups.com.
> To unsubscribe from this group, send email to sahana-eden...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sahana-eden?hl=en.
>
>
--
Amer
Fran Boon
> I'm not sure if I understood what you're suggesting here. If you're
> suggesting that a sync policy could favor particular field values, i.e
> in this case "Received always beats Delivered unless set by Admin", I
> don't think this is a good idea as it is tied to a particular module,
> field and set of values. Sync should work on a more generic level,
> shouldn't it?
Sync can support 'Strategies' for specific modules.
The base concept has been written into S3XRC by Dominic.
I'm not sure if support for this kind of Strategy is there yet -
you'll need to dig...
I copied Dominic's notes to the mailing list on this to the Wiki:
http://eden.sahanafoundation.org/wiki/S3XRC#Strategy
It's a real-world use-case, so I'd like to see it supported, although
it's not critical that this case be supported at this time...Sync
using strategies which can be set by the Sync Admin is definitely
required.
F
Amer Tahir
> On 4 July 2010 19:21, Amer Tahir <amer...@gmail.com> wrote:
>> I'm not sure if I understood what you're suggesting here. If you're
>> suggesting that a sync policy could favor particular field values, i.e
>> in this case "Received always beats Delivered unless set by Admin", I
>> don't think this is a good idea as it is tied to a particular module,
>> field and set of values. Sync should work on a more generic level,
>> shouldn't it?
>
> Sync can support 'Strategies' for specific modules.
> The base concept has been written into S3XRC by Dominic.
> I'm not sure if support for this kind of Strategy is there yet -
> you'll need to dig...
> I copied Dominic's notes to the mailing list on this to the Wiki:
> http://eden.sahanafoundation.org/wiki/S3XRC#Strategy
Sync strategies and resolutions support such kind of policies. During
sync, the sync_resolve method is called with the vector containing
details of the record being imported and it's up to sync_resolve to do
whatever it wants with the record. It can select values of fields
either from local or remote record and the use-case you specified can
be supported through such sync_resolve method. However, I'm not sure
what would be the best way to define these cases for the sync_resolve
method, right now it sees the sync policies and selects values for
fields depending on the policy chosen and modified date-time of local
and remote record.
> It's a real-world use-case, so I'd like to see it supported, although
> it's not critical that this case be supported at this time...Sync
> using strategies which can be set by the Sync Admin is definitely
> required.
Again, I'm not sure in what manner should the Sync Admin set such
strategies like preferring "Received" over "Delivered" for the
pledge_status field of RMS pledge resource.
Michael Howden
field in a specific table, stating the value C will beat value B, value B
will beat value A, etc...
> eden+uns...@googlegroups.com.
> >> For more options, visit this group at
> http://groups.google.com/group/sahana-eden?hl=en.
> >>
> >>
> >
> >
> >
> > --
> > Amer
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Sahana-Eden" group.
> > To post to this group, send email to sahan...@googlegroups.com.
> > To unsubscribe from this group, send email to sahana-
> eden+uns...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/sahana-eden?hl=en.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Sahana-Eden" group.
> To post to this group, send email to sahan...@googlegroups.com.
> To unsubscribe from this group, send email to sahana-
> eden+uns...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sahana-eden?hl=en.
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.830 / Virus Database: 271.1.1/2975 - Release Date: 07/04/10
> 00:05:00
Fran Boon
> the use-case you specified can
> be supported through such sync_resolve method. However, I'm not sure
> what would be the best way to define these cases for the sync_resolve
> method, right now it sees the sync policies and selects values for
> fields depending on the policy chosen and modified date-time of local
> and remote record.
This is the default strategy indeed, but we want Sync Admins to be
able to select from alternative strategies (like the simplistic 'we
win' & 'they win' & the 'by role' over-ride)
> Again, I'm not sure in what manner should the Sync Admin set such
> strategies like preferring "Received" over "Delivered" for the
> pledge_status field of RMS pledge resource.
So we have 2 parts to this I think:
(1) How does code know what to do?
(2) How do we expose this to UI?
For (1), we can add new vars: field & value_order for the field which
we want to have this type of rule applied & value order for the order
of winning values - e.g. field=priority&value_order=4>3
For (2), selecting this checkbox (as this acts as an over-ride to the
base policy, just like 'by role') which allows selection of the field
from a dropdown & value from another dropdown. A further enhancement
would be to have it detect the RMS case & offer this specific pair as
the default.
F
Praneeth Bodduluri
Slightly off topic, should we have some sort of an assisted componenet for sync? There might be scenarios in which an automated sync might not be the most consistent one, maybe an option to show a page, maybe through the proposed ticketting module, for the sync admin or an operator to manually decide which record needs to be retained.
One question: If you are giving time based priority for a record, what error in timestamps are acceptable? Since most often machines are not perfectly synced with an NTP and lose time over time.
--
Praneeth
-- Sent from my mobile device
On 5 Jul 2010 07:52, "Fran Boon" <franc...@gmail.com> wrote:
On 5 July 2010 06:33, Amer Tahir <amer...@gmail.com> wrote:
> the use-case you specified can
> be ...
This is the default strategy indeed, but we want Sync Admins to be
able to select from alternative strategies (like the simplistic 'we
win' & 'they win' & the 'by role' over-ride)
> Again, I'm not sure in what manner should the Sync Admin set such
> strategies like preferring "R...
So we have 2 parts to this I think:
(1) How does code know what to do?
(2) How do we expose this to UI?
For (1), we can add new vars: field & value_order for the field which
we want to have this type of rule applied & value order for the order
of winning values - e.g. field=priority&value_order=4>3
For (2), selecting this checkbox (as this acts as an over-ride to the
base policy, just like 'by role') which allows selection of the field
from a dropdown & value from another dropdown. A further enhancement
would be to have it detect the RMS case & offer this specific pair as
the default.
F
--
You received this message because you are subscribed to the Google Groups "Sahana-Eden" group.
To po...
Gavin Treadgold
Slightly off topic, should we have some sort of an assisted componenet for sync? There might be scenarios in which an automated sync might not be the most consistent one, maybe an option to show a page, maybe through the proposed ticketing module, for the sync admin or an operator to manually decide which record needs to be retained
Fran Boon
> Slightly off topic, should we have some sort of an assisted componenet for
> sync? There might be scenarios in which an automated sync might not be the
> most consistent one, maybe an option to show a page, maybe through the
> proposed ticketing module, for the sync admin or an operator to manually
> decide which record needs to be retained
> +1 I think a few of us have talked about this in the past where the two
> records are shown side by side, and the user/admin has the option of
> manually selecting which record should be accepted, and even allowing
> selection of individual fields from both to effectively and manually merge
> the two records into one.
Not off-topic at all.
UI to do manual resolution of merge conflicts with side-by-side
comparison is in-scope for GSoC 2010 :)
> There could conceivably be a higher level one that displays multiple at the
> same time that allows bulk reconciliations to be made.
Seems harder & not in scope for GSoC 2010, but if you could add some
ideas on this to the BluePrint then someone can pick it up later:
http://eden.sahanafoundation.org/wiki/BluePrintSynchronisation
Cheers,
F
Amer Tahir
that seems like a good plan. For (1), perhaps we can add drop-down for
module and resource as well with the option of "Any", so that it could
match to a particular field and value pair for any table (sync_resolve
would simply ignore where the table doesn't have that field). For (2),
exactly a drop-down would work, and maybe these policies would be
defined in the sync_policy table? Sync Admins could select the
Advanced option (when choosing policy from drop-down) where they could
select a previously defined policy or create new ones?
> F