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

Aaron Zeckoski azeckoski at unicon.net
Thu Jul 28 06:22:08 PDT 2011


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


More information about the sakai-dev mailing list