Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

[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?

  • No labels