[07:57:11 CST(-0600)] <Arvids> EricDalquist, are you here?
[07:57:21 CST(-0600)] <EricDalquist> yes
[07:57:22 CST(-0600)] <EricDalquist> kinda
[07:57:31 CST(-0600)] <EricDalquist> have the day off today
[07:57:42 CST(-0600)] <EricDalquist> but I figured I'd come and lurk since I knew you were working
[07:57:48 CST(-0600)] <Arvids> i saw your commit regarding @RequestCache
[07:58:06 CST(-0600)] <EricDalquist> yeah, it doesn't solve the xpath problem but it does mitigate it a bit
[07:58:24 CST(-0600)] <EricDalquist> on those xpath related methods it has about a 65% hit rate
[07:58:34 CST(-0600)] <EricDalquist> could be useful other places as well
[07:58:39 CST(-0600)] <Arvids> ahh... ok... i was wondering - maybe I should define some kinde of interface whose implementations could mimic the XPath expressions
[07:59:15 CST(-0600)] <Arvids> and use those implementations instead of my currently offered code
[07:59:21 CST(-0600)] <EricDalquist> well I'd be interested if you re-test to see how much time that xpath work is still taking
[07:59:24 CST(-0600)] <EricDalquist> right
[07:59:35 CST(-0600)] <EricDalquist> the other thing would be just to move that logic you have into the single tab helper class
[07:59:48 CST(-0600)] <EricDalquist> get the layout DOM from the user layout manager
[07:59:56 CST(-0600)] <EricDalquist> and do the traversal
[08:00:06 CST(-0600)] <Arvids> that one particular helper could be an implementation of that interface
[08:00:29 CST(-0600)] <EricDalquist> yeah, that seems reasonable
[08:00:43 CST(-0600)] <Arvids> I´ll now do another pull request
[08:00:49 CST(-0600)] <Arvids> please, review the code
[08:01:00 CST(-0600)] <EricDalquist> really your previous patch was functionally good it just needed to be redistributed a bit so that the functionality was correctly plugable
[08:01:24 CST(-0600)] <EricDalquist> will do 
[08:02:12 CST(-0600)] <Arvids> https://github.com/agrabovskis/uPortal/commit/666d1c6549d739e006b2429943be6c8a416fa3f7
[08:02:52 CST(-0600)] <Arvids> hmm... github says that master branch is already up-to-date
[08:03:27 CST(-0600)] <EricDalquist> when trying to do a pull?
[08:03:59 CST(-0600)] <Arvids> lol - it incorporated the second commit although I pushed it after pull request... didn´t know such behaviour
[08:04:09 CST(-0600)] <EricDalquist> weird
[08:04:22 CST(-0600)] <EricDalquist> either did I
[08:05:26 CST(-0600)] <Arvids> anyways... it turns out that Hibernate is unable to load object graph if you´re not loading it via entityManager.find(...)
[08:05:59 CST(-0600)] <Arvids> this resulted in lots of SELECTs while loading stylesheet user preferences
[08:06:18 CST(-0600)] <EricDalquist> really? I could have sworn it honored the join configs when running queries
[08:06:23 CST(-0600)] <Arvids> it seems that selecting for ID and later loading by retrieved id is faster
[08:06:45 CST(-0600)] <Arvids> it showed me a lot of selects and not a single join
[08:07:00 CST(-0600)] <EricDalquist> huh
[08:07:06 CST(-0600)] <EricDalquist> thats good to know
[08:07:13 CST(-0600)] <Arvids> https://community.jboss.org/wiki/HibernateFAQ-AdvancedProblems#Hibernate_ignores_my_outerjointrue_or_fetchjoin_setting_and_fetches_an_association_lazily_using_n1_selects
[08:07:16 CST(-0600)] <EricDalquist> I'll have to take a look at the unit tests for the jpa daos again
[08:07:39 CST(-0600)] <EricDalquist> ahhh
[08:07:42 CST(-0600)] <Arvids> I assume the same behaviour applies for EntityManager (not only hibernate´s Session)
[08:07:44 CST(-0600)] <EricDalquist> ok I think we can work around this
[08:07:52 CST(-0600)] <EricDalquist> using criteria builder
[08:08:12 CST(-0600)] <EricDalquist> you can essentially tell the query builder explicitly to load certain collections
[08:08:36 CST(-0600)] <Arvids> yeah, but that turns your criteria building a nightmare
[08:08:53 CST(-0600)] <Arvids> lot´s of stuff to tell that you´ve already declared via annotations
[08:09:10 CST(-0600)] <EricDalquist> yeah
[08:26:19 CST(-0600)] <EricDalquist> so making jpa fetch collections is pretty easy
[08:26:45 CST(-0600)] <EricDalquist> for example in JpaStylesheetDescriptorDao I added:
[08:26:46 CST(-0600)] <EricDalquist> descriptorRoot.fetch(StylesheetDescriptorImpl_.layoutAttributes);
[08:26:46 CST(-0600)] <EricDalquist> descriptorRoot.fetch(StylesheetDescriptorImpl_.outputProperties);
[08:26:46 CST(-0600)] <EricDalquist> descriptorRoot.fetch(StylesheetDescriptorImpl_.stylesheetParameters);
[08:27:02 CST(-0600)] <EricDalquist> that then results in a single query to load the descriptor and all three maps
[08:27:29 CST(-0600)] <EricDalquist> really I can't wait for the natural-id loading stuff that I've been helping the hibernate folks with
[08:27:38 CST(-0600)] <EricDalquist> it will really solve a lot of our db related loading issue
[08:27:40 CST(-0600)] <EricDalquist> issues
[08:37:00 CST(-0600)] <Arvids> this part i did figure out, but it retrieved a lot of attribute duplicates... and that was the part where I gave up
[08:40:14 CST(-0600)] <EricDalquist> ah well it always well
[08:40:18 CST(-0600)] <EricDalquist> that is the nature of joins
[08:40:37 CST(-0600)] <EricDalquist> the stuff in the primary entity will be listed in every result row
[08:42:45 CST(-0600)] <Arvids> that irritates me - why do I have to tell JPA same things over and over again? Isn´t that the point of ORM - single point of configuration for each entity?
[08:43:18 CST(-0600)] <Arvids> after all - that´s the reason why we´re using typesafe queries
[08:48:35 CST(-0600)] <EricDalquist> yeah, that is annoying
[08:48:51 CST(-0600)] <EricDalquist> but this does reduce queries even more
[08:49:03 CST(-0600)] <EricDalquist> query for id then load by id can be 2 queries
[08:49:08 CST(-0600)] <EricDalquist> this will be one at most
[08:49:25 CST(-0600)] <Arvids> agree