[samigo-team] No POJO's?

[David Horwitz]

Thanks!

I took the liberty under https://jira.sakaiproject.org/browse/SAM-1614 
to write some unit tests to cover this method. If inapropriate let me 
know and I will reverse them

D

On 03/02/2012 03:41 AM, Karen Tsao wrote:
> I see.
>
> I am afraid I cannot give you much information as I didn't involve in 
> the original Samigo design. Therefore, please implement the way you 
> think it should be  :)
>
> Thanks,
> Karen
>
> On Thu, Mar 1, 2012 at 7:57 AM, David Horwitz <david.horwitz at uct.ac.za 
> <mailto:david.horwitz at uct.ac.za>> wrote:
>
>     I was actually thinking of converting some of the interface-impl
>     to POJO's for the date objects. i.e adding POJO's not removing
>     them ;-)
>
>
>     D
>
>
>     On 02/29/2012 11:04 PM, Karen Tsao wrote:
>>     Hi David,
>>
>>     Some of the POJOs were there to satisfy the OKI mandate we had
>>     initially and they can be taken out. It was there purely to
>>     satisify the mellon grant requirement of implementing OKI OSIDs.
>>     Is this what you refer to? If not, can you please give us some
>>     examples?
>>
>>     Thanks,
>>     Karen
>>
>>     On Wed, Feb 29, 2012 at 7:47 AM, David Horwitz
>>     <david.horwitz at uct.ac.za <mailto:david.horwitz at uct.ac.za>> wrote:
>>
>>         Hi All,
>>
>>         In trying to track down the cause of excesive queries queries in
>>         assessment taking. I'm struggling to get to the bottom of 1
>>         patern, I
>>         have a suspect but fixing will mean widepread changes and
>>         change a
>>         design pattern in Samigo.
>>
>>         The problem is this:
>>
>>         When a student navigates between sections their
>>         AssessmentGradingData
>>         item is saved, causing all their ItemGradingData objects to
>>         be updated,
>>         whether they have d changed or not.
>>
>>
>>         I've made some had changes to the hibernate config (made the
>>         relation
>>         bi-derectional) to no affect. As a second step I I'm looking at
>>         overiding hashCode and equals and to put it one way - the
>>         errors suggest
>>         that this is the right path. However the this is complicated
>>         in that
>>         there are 2 separate implementations of these domain objects.
>>
>>
>>         Is there a reason the API could not be done away with and the
>>         objects be
>>         changed to a single POJO? This is a hibernate design pattern
>>         I'm more
>>         familiar with.
>>
>>
>>         Regards
>>
>>         D
>>
>>
>>
>>
>>
>>         _______________________________________________
>>         samigo-team mailing list
>>         samigo-team at collab.sakaiproject.org
>>         <mailto:samigo-team at collab.sakaiproject.org>
>>         http://collab.sakaiproject.org/mailman/listinfo/samigo-team
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/samigo-team/attachments/20120302/08a8b567/attachment.html