[Contrib: Evaluation System] Questions about evalsys

[Aaron Zeckoski]

On Fri, Jan 29, 2010 at 3:24 PM, Jim Eng <jimeng at umich.edu> wrote:
> Hi Aaron,
>
> I have a few questions I'm hoping you can help me with.
>
> 1) I am using XStream to serialize and deserialize EVAL entities for
> export/import. XStream has a known issue with hibernate's lazy
> initialization.  Is there a way through the existing EVAL API's to turn off
> lazy init (i.e. to get a fully initialized object) for entities before they
> go to XStream?

If there is then I don't know about it. I ended up writing my own
serializer for EB because I could not make the one for xstream work.
If you do find a way to make this work then let me know.

> 2) The EvalEmailTemplate class does not have an EID, but we need to import
> email templates and link from other entities to particular email templates
> on import. Is it OK to add an EID member to the class and to its hibernate
> mapping, provided appropriate tests are added?  Is it OK to add a
> getEmailTemplateByEid(String) method to the Evaluation Service (along with
> an appropriate test)?

Yeah. Definitely.


> 3) There's a problem with trying to update an existing EvalItem.  We
> discussed this a week or so ago, but I haven't worked it out yet.  When
> calling EvalAuthoringService.saveItem() and passing in an existing EvalItem
> to be updated, the saveItem() method retrieves the object again at line 398.
>  There's a comment there that says you just get back the same object, but
> that's not my experience.  I get a hibernate exception a few lines later
> because I'm trying to save a different object than the one that was most
> recently retrieved from the db. The object is being retrieved at line 398 to
> check whether it is locked in the db (as opposed to trusting that the object
> being passed in). Noah mentioned that it might be possible to evict that
> newly retrieved object from the hibernate session so the other one can be
> saved.  It occurs to me that maybe this would be better handled by adding a
> method to check whether an item is locked without actually retrieving it.
>  There was similar code in save methods for other entity types, but those
> lines have been commented out, so it looks like the locked property is being
> checked only when saving items of type EvalItem. (I could mention a few
> other details, but before I do, I'm wondering if you have a preference about
> an approach to solving this).

I think we basically stopped using the locks when everyone decided
they preferred to make duplication rather than reference copied of
object trees. That got rid of most of the need for the locks.
That said, I have special methods in the DAO to checks locks which
might be better to use in this circumstance. On the other hand, it may
simply be best to remove the lock check entirely since the other ones
are not really being done anymore.
I am open to solutions on this and frankly the extra lock check is
probably overkill. Not trusting the object does mean that a developer
could change a locked object but I suppose that could happen anyway.
What do you think of those options? Any of them sound good?

Hope this helps!
-AZ


-- 
Aaron Zeckoski (azeckoski (at) vt.edu)
Senior Research Engineer - CARET - University of Cambridge
https://twitter.com/azeckoski - http://www.linkedin.com/in/azeckoski
http://aaronz-sakai.blogspot.com/ - http://tinyurl.com/azprofile