[Building Sakai] [maint] Entity References Broken During Site Import: Solution Vote (KNL-737 or SAK-16568)

[Bryan Holladay]

Ok... Good idea... I'll make sure that gets modified so there isn't a kernel
API breakage.  So lets pretend it's already done for the rest of this
conversion.

Sakai Community... Thoughts on these solutions?  Votes?

On Thu, Jul 28, 2011 at 9:41 AM, Aaron Zeckoski <azeckoski at unicon.net>wrote:

> Right.... so you make a new method which returns the map and then if
> that method is not implemented, you can call the old one as a fallback
> from the service (even though it is less functional).
> :-)
> -AZ
>
>
> On Thu, Jul 28, 2011 at 9:25 AM, Bryan Holladay <holladay at longsight.com>
> wrote:
> > I would have done that except that I had to modify the existing API to
> > return a Map of the references instead of void:
> >
> > - void transferCopyEntities(String fromContext, String toContext, List
> ids);
> > + Map<String, String> transferCopyEntities(String fromContext, String
> > toContext, List ids);
> > If it was just an addition of a stub, then your solution would be the
> > preferred way.
> > The zip is the patch... there are 15+ patches in that zip.
> > -Bryan
> >
> >
> > On Thu, Jul 28, 2011 at 9:22 AM, Aaron Zeckoski <azeckoski at unicon.net>
> > wrote:
> >>
> >> I'm, not a fan of a new required interface which cause compilation to
> >> break. When we extended the API for UDS we did it by adding optional
> >> APIs which could be implemented (much like we do for EB) without
> >> changing the original API. This has the advantage of not breaking
> >> everything that exists and allowing people to extend it when they
> >> want/have time. I recommend an approach like this.
> >>
> >> Is there somewhere I can see a patch file for the API you have
> >> proposed? I only saw a zip file on the ticket in question.
> >> -AZ
> >>
> >>
> >> On Thu, Jul 28, 2011 at 9:07 AM, Bryan Holladay <holladay at longsight.com
> >
> >> wrote:
> >> > No problem... I'll get the ball rolling.
> >> > We need to get at least one of these jira's in trunk.  There are two
> >> > solutions (KNL-737 and SAK-16568).  I'll start by describing my patch
> >> > then
> >> > Matt can describe his and maybe we can make an educated decision here?
> >> >  Either way, the community should decide if they want one of these
> >> > solutions
> >> > or none.
> >> > Problem:
> >> > When importing data from an external site, Sakai's Entity references
> >> > continue to point to previous site's data.  Sakai needs a way to
> ensure
> >> > these references get updated during the import process.  This is
> >> > particularly important for tools like Entity Picker and LessonBuilder.
> >> >
> >> > Solutions:
> >> > SAK-16568 or KNL-737
> >> > I'll describe my patch and Matt can describe his:
> >> > SAK-16568 Entity picker link points to original site when 'Import from
> >> > Site'
> >> > option is used
> >> > (https://jira.sakaiproject.org/browse/SAK-16568)
> >> > Detailed Description:
> >> > Extends the EntityTransferrer API to return a Map<FromContext ->
> >> > ToContext>
> >> > for every item that is transfered to the new site.  This includes all
> >> > item
> >> > ref's (ex. assignment refs, forum refs, topic refs, ect) since most
> >> > information isn't based on Site ID.
> >> > Extends the EntityTransferrer API to add an implementable stub that is
> >> > called after all information is collected.  It sends over the
> collective
> >> > Map<FromContext->ToContext> to each tool in order to update any
> >> > references
> >> > in that tool's item's text (or where ever that tool wants to update
> it's
> >> > references).
> >> > Workflow:
> >> > -Entity Transferrer collects all the FrontContext->ToContext
> information
> >> > from all the tools being transfered
> >> > -Since Resources is a separate action outside of Entity Transferrer,
> it
> >> > collects the reference Map for resources as well
> >> > -Entity Transferrer sends the FrontContext->ToContext information to
> all
> >> > the
> >> > tools being transfered as well as the Site Context Old->New
> >> > Notes
> >> > I've already implemented all of Sakai's tools and some indy tools
> (some
> >> > tools are just empty stubs).  The drawback is that since this changes
> >> > the
> >> > Kernel's API, any indy project that uses EntityTransferrer will need
> to
> >> > have
> >> > an empty stub implemented to compile, but this is very simple.
> >> >
> >> >
> >> > Any votes or comments would be greatly appreciated.
> >> > Thanks,
> >> > Bryan
> >> >
> >> >
> >> >
> >> > On Thu, Jul 28, 2011 at 8:23 AM, Steve Swinsburg
> >> > <steve.swinsburg at gmail.com>
> >> > wrote:
> >> >>
> >> >> Hey Bryan,
> >> >> I haven't done anything on it, I posited it to the TCC (or maybe MT)
> a
> >> >> couple of times, no response. Matthew Bucket has also done some work
> on
> >> >> it
> >> >> (latest comment in that JIRA), want to compare notes with him?
> >> >> cheers
> >> >> s
> >> >>
> >> >> On 28/07/2011, at 10:19 PM, Bryan Holladay wrote:
> >> >>
> >> >> Any word on https://jira.sakaiproject.org/browse/SAK-16568?  I
> remember
> >> >> at
> >> >> the conference you were talking about getting this into trunk.  I've
> >> >> tried
> >> >> before, it's no easy task :)
> >> >
> >> >
> >> > _______________________________________________
> >> > mt mailing list
> >> > mt at collab.sakaiproject.org
> >> > http://collab.sakaiproject.org/mailman/listinfo/mt
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> >
> >
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110728/505be589/attachment.html