[14:07:55 CDT(-0500)] <athena> EricDalquist: working on the new fragment administration interface, and it seems like it's not loading evaluators
[14:08:16 CDT(-0500)] <athena> do you know if the query to fetch fragment definitions should do a join on child evaluators by default?
[14:08:29 CDT(-0500)] <EricDalquist> hrm
[14:08:41 CDT(-0500)] <EricDalquist> well the model should be consistent when you get it back
[14:08:49 CDT(-0500)] <EricDalquist> but you might need to do explicit fetches
[14:08:53 CDT(-0500)] <EricDalquist> to prevent lazy loadin
[14:09:03 CDT(-0500)] <athena> yeah, was wondering about that
[14:09:18 CDT(-0500)] <athena> right now using FragmentDefinitionDao.getFragmentDefinitionByOwner
[14:09:33 CDT(-0500)] <athena> some similar functionality uses the getAllFragments in the background and seems to work fine
[14:09:59 CDT(-0500)] <athena> but thinking through it, i guess that one explicitly interacts with the getEvaluators method on the returned objects in the java code, whereas this code just interacts with it via the JSP
[14:10:06 CDT(-0500)] <athena> how's our lazy loading set up right now?
[14:10:30 CDT(-0500)] <EricDalquist> well ... we try to avoid it as much as possible
[14:10:39 CDT(-0500)] <athena> sounds reasonable to me
[14:11:15 CDT(-0500)] <EricDalquist> fragDefRoot.fetch(FragmentDefinition_.evaluators);
[14:11:17 CDT(-0500)] <EricDalquist> try adding that
[14:11:18 CDT(-0500)] <EricDalquist> at line 79
[14:11:27 CDT(-0500)] <athena> will do
[14:11:34 CDT(-0500)] <EricDalquist> that fragment data model is really gross in general
[14:11:39 CDT(-0500)] <athena> do we want to just explicitly fetch all the time on all methods?
[14:11:42 CDT(-0500)] <athena> yeah, it's awful :/
[14:11:50 CDT(-0500)] <EricDalquist> JPA's inheritence model + a tree structure == lots of pain
[14:12:02 CDT(-0500)] <athena> i remember we were also pretty limited in what we could do without changing the API / database
[14:12:11 CDT(-0500)] <athena> hopefully we can improve it for 4.1
[14:12:18 CDT(-0500)] <EricDalquist> yeah, we'll see
[14:12:34 CDT(-0500)] <athena> it seems like we probably want to explicitly prefetch in this case? i can't imagine the fragment def being very useful w/o any evaluators
[14:12:46 CDT(-0500)] <EricDalquist> yup
[14:13:04 CDT(-0500)] <EricDalquist> in general we try to explicitly add fetch calls to the query everywhere
[14:13:28 CDT(-0500)] <athena> isn't there a way to indicate prefetching as an annotation on the object, too?
[14:28:50 CDT(-0500)] <EricDalquist> yes
[14:28:54 CDT(-0500)] <EricDalquist> but that doesn't apply to queries
[14:29:00 CDT(-0500)] <EricDalquist> its weird
[14:29:05 CDT(-0500)] <EricDalquist> there are two ways to get jpa objects
[14:29:08 CDT(-0500)] <EricDalquist> one is a direct load
[14:29:28 CDT(-0500)] <EricDalquist> entityManager.load(id, Entitytype.class)
[14:29:38 CDT(-0500)] <EricDalquist> that honors all of your lazy/eager/fetch annotations
[14:29:45 CDT(-0500)] <EricDalquist> the hibernate naturalId query does too
[14:29:54 CDT(-0500)] <EricDalquist> general queries though
[14:30:07 CDT(-0500)] <EricDalquist> you have to specify fetches explicitly
[14:30:22 CDT(-0500)] <athena> ahhh
[14:30:24 CDT(-0500)] <athena> gotcha
[14:30:27 CDT(-0500)] <athena> that makes sense then
[15:15:56 CDT(-0500)] <EricDalquist> hrm ... found an off by one issue with report queries
[15:16:01 CDT(-0500)] <EricDalquist> not sure how that happens
[15:16:07 CDT(-0500)] <EricDalquist> time to dig into the sql more :/
[15:22:29 CDT(-0500)] <athena> ick
[15:22:35 CDT(-0500)] <athena> something in the fill int he blanks logic?
[15:22:38 CDT(-0500)] <EricDalquist> kinda
[15:22:50 CDT(-0500)] <EricDalquist> when I query for a day
[15:23:00 CDT(-0500)] <EricDalquist> the first result is for Dx
[15:23:09 CDT(-0500)] <EricDalquist> but the date range list is Dx+1
[15:23:10 CDT(-0500)] <EricDalquist> hrm
[15:23:11 CDT(-0500)] <EricDalquist> actually
[15:23:17 CDT(-0500)] <EricDalquist> the first result is Dx-1
[15:23:22 CDT(-0500)] <EricDalquist> and the date range list is Dx
[15:23:28 CDT(-0500)] <EricDalquist> so I think it is a problem in the query
[15:23:29 CDT(-0500)] <EricDalquist> we'll see
[15:23:30 CDT(-0500)] <athena> huh.
[15:23:33 CDT(-0500)] <athena> meanwhile i'm not sure what's going on w/ this fragment defs thing
[15:23:39 CDT(-0500)] <EricDalquist> :/
[15:23:44 CDT(-0500)] <athena> i see the fragmentDefinitionDao returning the right thing in the debugger
[15:23:44 CDT(-0500)] <EricDalquist> you can turn on SQL debugging
[15:23:51 CDT(-0500)] <EricDalquist> ah
[15:24:00 CDT(-0500)] <athena> but then if i set a breakpoint at getEvaluators(), when the JSP calls that method the list is empty
[15:24:05 CDT(-0500)] <athena> so no idea what's happening there
[15:24:18 CDT(-0500)] <EricDalquist> so it is correct in the controller
[15:24:23 CDT(-0500)] <EricDalquist> and broken in the jsp?
[15:24:26 CDT(-0500)] <athena> web flow
[15:24:37 CDT(-0500)] <EricDalquist> aj
[15:24:38 CDT(-0500)] <EricDalquist> ah
[15:24:46 CDT(-0500)] <athena> so the Dao is at least returning the right thing, but by the time the JSP gets it it's lost it's list
[15:25:07 CDT(-0500)] <athena> not sure i really have a hypothesis for why that'd happen
[15:25:43 CDT(-0500)] <EricDalquist> uhg
[15:25:48 CDT(-0500)] <EricDalquist> is it the same object in both places?
[15:25:52 CDT(-0500)] <EricDalquist> like a PersistentList?
[15:27:59 CDT(-0500)] <athena> hm, i'll look
[15:28:26 CDT(-0500)] <athena> but i noticed that the fragment definiton has a different @blahblah in the name in the debugger