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 24 Current »

[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 (smile)

[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

[08:53:42 CST(-0600)] <Arvids> ... then my last commit should be reverted and previous criteria building changed

[08:54:11 CST(-0600)] <EricDalquist> yeah, no problem

[10:02:27 CST(-0600)] <Arvids> https://github.com/Jasig/uPortal/pull/18

[10:04:34 CST(-0600)] <Arvids> Feel free to suggest any improvements/refactorings needed

[10:05:17 CST(-0600)] <Arvids> tomorrow i´ll try to tinker the stylesheet user preferences code

[10:09:59 CST(-0600)] <EricDalquist> sounds good, I'll take a look shortly

[10:15:06 CST(-0600)] <Arvids> take your time... I don´t want to feel guilty for stealing your day off (tongue)

[10:44:56 CST(-0600)] <dd_> hello

[10:45:16 CST(-0600)] <dd_> trying to setup SmartLdapGroupStore

[10:45:24 CST(-0600)] <dd_> i was using PAGS before

[10:45:33 CST(-0600)] <dd_> i followed this guide: https://wiki.jasig.org/display/UPM32/SmartLdapGroupStore

[10:45:49 CST(-0600)] <dd_> logged in, how would i tell if SmartLdapGroupStore is setup?

[13:07:50 CST(-0600)] * Topic is 'http://uportal.pastebin.com/ - https://wiki.jasig.org/display/UPC/uportal+IRC+Logs' set by EricDalquist!~apollo@76.210.64.142 on 17:44:12 CDT(-0500)

  • No labels