uPortal IRC Logs-2009-03-11

Owned by Apereo Infrastructure
Last updated: Mar 11, 2009Version comment
14 min read

[00:17:49 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal
[04:15:52 EDT(-0400)] * higmad (n=chatzill@pcit-8752.hig.se) has joined ##uportal
[07:28:49 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[08:31:21 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[08:36:33 EDT(-0400)] <dstn> athena, what happen to your 7?
[08:36:38 EDT(-0400)] <dstn> not feeling so lucky?
[08:36:49 EDT(-0400)] <athena> lol
[08:36:58 EDT(-0400)] <athena> i got ahold of the base nick
[08:37:10 EDT(-0400)] <athena> it had been registered before
[08:37:22 EDT(-0400)] <dstn> ah
[08:44:42 EDT(-0400)] * athena stages a hostile nick takeover
[08:49:25 EDT(-0400)] * tsnfoo_ (n=tsnfoo@140.141.215.32) has joined ##uportal
[08:57:02 EDT(-0400)] <dstn> athena, whoa whoa, take it easy
[08:57:11 EDT(-0400)] <dstn> put the nick down
[08:57:15 EDT(-0400)] <dstn> nice and easy
[08:57:18 EDT(-0400)] <athena> nooooo
[08:57:34 EDT(-0400)] <athena> (smile)
[08:57:45 EDT(-0400)] * dstn we've got a hostile situation, we're gonna need backup
[09:02:44 EDT(-0400)] <athena> backups are good
[09:05:06 EDT(-0400)] * dstn lost eclipse
[09:05:10 EDT(-0400)] <athena> (sad)
[09:05:22 EDT(-0400)] <dstn> nm, I found it
[09:19:58 EDT(-0400)] <athena> it'd be bad to lose eclipse
[09:19:59 EDT(-0400)] <athena> don't do that
[09:24:21 EDT(-0400)] <dstn> ya, the stupid window manager puts it in other desktop workspaces when I start it sometimes
[09:24:46 EDT(-0400)] <dstn> then its like...I swear I started Eclipse a min ago...where'd it go
[09:24:51 EDT(-0400)] <athena> lol
[09:25:00 EDT(-0400)] <athena> mine eclipse has been a bit finicky lately
[09:25:10 EDT(-0400)] <athena> probably need to clean out my workspace
[09:25:14 EDT(-0400)] <athena> too much stuff in there
[09:26:45 EDT(-0400)] <dstn> ya, Eclipse gets weird after a while
[09:27:09 EDT(-0400)] <dstn> I find myself starting fresh a lot
[09:28:38 EDT(-0400)] * bszabo (n=bszabo@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[09:32:42 EDT(-0400)] <athena> uhoh, computer misbehaving
[09:36:57 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined ##uportal
[09:42:47 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[09:45:58 EDT(-0400)] * SusanBramhall (i=susanbra@dhcp128036154104.central.yale.edu) has joined ##uportal
[09:48:31 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined ##uportal
[10:08:17 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131712.dsl.bell.ca) has joined ##uportal
[10:16:04 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:17:19 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined ##uportal
[10:26:52 EDT(-0400)] <athena> EricDalquist: i haven't yet replicated that tabs issue, so hopefully i just did something terrible to my database
[10:27:01 EDT(-0400)] <EricDalquist> (smile)
[10:27:20 EDT(-0400)] <athena> i may try messing around w/ the DLM fragments though, just to make sure
[10:39:54 EDT(-0400)] <athena> has anyone tried building the duke mail portlet recently?
[10:45:04 EDT(-0400)] <athena> by the way EricDalquist
[10:45:14 EDT(-0400)] <athena> i've been playing w/ our ajax portlet tools the last few days
[10:45:19 EDT(-0400)] <athena> seems really nice for the most part
[10:45:52 EDT(-0400)] <athena> although if you hit an uncaught exception, things go pretty haywire - you sort of see the whole portlet load within that portlet, then the page explodes and the google search portlet takes over
[10:46:01 EDT(-0400)] <EricDalquist> yeah
[10:46:09 EDT(-0400)] <EricDalquist> the error handling portal side will hose it
[10:46:26 EDT(-0400)] <athena> i'm not sure what we want to do about that
[10:46:36 EDT(-0400)] <EricDalquist> try { } catch (Execption e) { }
[10:46:43 EDT(-0400)] <athena> right
[10:46:48 EDT(-0400)] <EricDalquist> the ajax response controller really needs to do that
[10:46:55 EDT(-0400)] <athena> yeah, that was more my point
[10:46:56 EDT(-0400)] <EricDalquist> and always return content
[10:47:03 EDT(-0400)] <EricDalquist> it will be good to get uportal supporting jsr-286
[10:47:07 EDT(-0400)] <athena> that we may need to add it into the tool itself to prevent people having to do it themselves
[10:47:10 EDT(-0400)] <EricDalquist> ah
[10:47:12 EDT(-0400)] <athena> yeah, that wil be nice
[10:47:13 EDT(-0400)] <EricDalquist> feel free
[10:47:29 EDT(-0400)] <athena> though i'm not sure how it's going to impact some of our javascript stuff
[10:54:54 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has joined ##uportal
[10:55:39 EDT(-0400)] <dstn_> EricDalquist, so we have a pretty tight schedule to get to our uP 3.1 instance and given my very limited knowledge of the deep internals of DLM. We are most likely look to have Unicon finish the dlm issues I pointed out yesterday when they are here in April.
[10:55:49 EDT(-0400)] <EricDalquist> ok
[10:56:00 EDT(-0400)] <EricDalquist> oh and dstn can you file a jira for that db import issue you ran into?
[10:56:11 EDT(-0400)] <dstn> and of course I'm sure they'd commit it back
[10:56:12 EDT(-0400)] <dstn> yep, np
[10:56:13 EDT(-0400)] <EricDalquist> we have more control over the tables.xml file used for the plain db target
[10:56:30 EDT(-0400)] <EricDalquist> so that I think should fail on error and we just need to clean up tables.xml to not cause errors
[10:56:53 EDT(-0400)] <dstn> ok
[10:57:52 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[11:00:49 EDT(-0400)] <dstn> http://www.ja-sig.org/issues/browse/UP-2354
[11:00:56 EDT(-0400)] <EricDalquist> thanks
[11:01:00 EDT(-0400)] <dstn> np
[11:09:49 EDT(-0400)] * SusanB (i=susanbra@susan-x200.its.yale.edu) has joined ##uportal
[11:16:35 EDT(-0400)] * lennard1 (n=sparhk@ip68-98-56-21.ph.ph.cox.net) has left ##uportal
[11:30:58 EDT(-0400)] * SusanB (i=susanbra@susan-x200.its.yale.edu) has left ##uportal
[11:31:38 EDT(-0400)] * SusanBramhall (i=susanbra@susan-x200.its.yale.edu) has joined ##uportal
[11:43:47 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:45:50 EDT(-0400)] <dstn> EricDalquist, was there additional constraint work done between RC1 and RC2?
[11:46:30 EDT(-0400)] <EricDalquist> I don't think so
[11:46:38 EDT(-0400)] <EricDalquist> other than adding a bunch of not-nulls
[11:46:47 EDT(-0400)] <EricDalquist> so I guess yes then (smile)
[11:46:53 EDT(-0400)] <dstn> lol, ok
[11:47:10 EDT(-0400)] <EricDalquist> we found that some DBs fail if you have a column in a PK that can be null
[11:47:37 EDT(-0400)] <dstn> getting a few unique constraint violations, trying to track them down
[11:48:07 EDT(-0400)] <EricDalquist> on data import?
[11:48:26 EDT(-0400)] <dstn> ya
[11:48:40 EDT(-0400)] <dstn> one sec
[11:50:24 EDT(-0400)] <dstn> on this
[11:50:25 EDT(-0400)] <dstn> INSERT INTO up_group(creator_id, description, entity_type_id, group_name, group_id)
[11:50:25 EDT(-0400)] <dstn> VALUES(?, ?, ?, ?, ?)
[11:50:39 EDT(-0400)] <dstn> as far as I can tell...the only unique column is the primary key
[11:51:19 EDT(-0400)] <EricDalquist> are you using the data.xml included with up3?
[11:51:26 EDT(-0400)] <EricDalquist> and are you importing that before running crn-import?
[11:52:51 EDT(-0400)] <dstn> yes, doing a full initdb but pointing to our entities during the crn-import phase
[11:53:17 EDT(-0400)] <EricDalquist> my only thought there was data.xml defines some initial data for the up sequence table
[11:53:29 EDT(-0400)] <EricDalquist> which should result in the first 10 group ids being reserved for special groups
[11:53:39 EDT(-0400)] <EricDalquist> can you see the data it is trying to insert?
[11:55:30 EDT(-0400)] <dstn> no, I was trying to figure out how to get it to display that...I turned the portal.io package up to debug on a whim
[11:55:38 EDT(-0400)] <EricDalquist> just a sec ...
[11:55:46 EDT(-0400)] <dstn> interesting note is that 1-10 are already taken in the db
[11:55:54 EDT(-0400)] <dstn> by non special groups
[11:55:56 EDT(-0400)] <EricDalquist> log4j.category.org.springframework.jdbc.core=TRACE, SQL
[11:55:56 EDT(-0400)] <EricDalquist> log4j.additivity.org.springframework.jdbc.core=false
[11:56:01 EDT(-0400)] <dstn> so that sounds like the problem
[11:56:07 EDT(-0400)] <EricDalquist> cernunnos uses spring-jdbc
[11:56:10 EDT(-0400)] <EricDalquist> yeah
[11:56:13 EDT(-0400)] <EricDalquist> that shouldn't be happening
[11:56:46 EDT(-0400)] <EricDalquist> in the initdb steps
[11:56:49 EDT(-0400)] <EricDalquist> after the db task is done
[11:56:56 EDT(-0400)] <EricDalquist> but before crn-import runs
[11:57:06 EDT(-0400)] <EricDalquist> UP_SEQUENCE should have one row
[11:57:13 EDT(-0400)] <EricDalquist> where the name is UP_GROUP and the value is 10
[12:07:43 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:49:53 EDT(-0400)] * [jlee] (n=jlee@68.208.122.33) has joined ##uportal
[12:52:20 EDT(-0400)] * [jlee_] (n=jlee@68.208.122.33) has joined ##uportal
[13:24:17 EDT(-0400)] <dstn> so the data not being populated was related to UP-2354...I thought if i just removed failonerror=true it would continue to execute the other statements...doh
[13:24:58 EDT(-0400)] <EricDalquist> (smile)
[13:25:07 EDT(-0400)] <dstn> is fixing UP-2354 as simple as adding the same try catch as what's in the block above it
[13:25:29 EDT(-0400)] <dstn> or is it more complex than that
[13:26:23 EDT(-0400)] <EricDalquist> remove
[13:26:24 EDT(-0400)] <EricDalquist> <index>
[13:26:24 EDT(-0400)] <EricDalquist> <name>UPU_NAME_IDX</name>
[13:26:24 EDT(-0400)] <EricDalquist> <column-ref>USER_NAME</column-ref>
[13:26:24 EDT(-0400)] <EricDalquist> </index>
[13:26:27 EDT(-0400)] <EricDalquist> from tables.xml
[13:26:30 EDT(-0400)] <EricDalquist> in the up_user table def
[13:26:43 EDT(-0400)] <EricDalquist> the problem is USER_NAME is the PK and there is an index on it
[13:26:47 EDT(-0400)] <EricDalquist> which isn't right
[13:27:11 EDT(-0400)] <EricDalquist> you can probabluy remove
[13:27:11 EDT(-0400)] <EricDalquist> <unique>
[13:27:11 EDT(-0400)] <EricDalquist> <name>UPU_NAME_UNQ</name>
[13:27:11 EDT(-0400)] <EricDalquist> <column-ref>USER_NAME</column-ref>
[13:27:11 EDT(-0400)] <EricDalquist> </unique>
[13:27:19 EDT(-0400)] <EricDalquist> since the PK also implies uniqueness
[13:30:43 EDT(-0400)] <dstn> do primary keys always have indexes on them by default?
[13:31:27 EDT(-0400)] <EricDalquist> a primary key == a unique index
[13:32:31 EDT(-0400)] <athena> i think a primary key is required to be unique and non-null, yes?
[13:33:11 EDT(-0400)] * dstn doesn't know much about indexes
[13:33:17 EDT(-0400)] <dstn> anyways, thanks EricDalquist
[13:33:43 EDT(-0400)] <EricDalquist> so some databases allow null primary keys (oracle I think does)
[13:34:05 EDT(-0400)] <EricDalquist> though oracle has the horrible convention that null == ""
[13:36:06 EDT(-0400)] <athena> ack
[13:37:02 EDT(-0400)] <EricDalquist> yup
[13:37:16 EDT(-0400)] <EricDalquist> there is special code in the portal in a few places to handle that
[13:37:29 EDT(-0400)] <EricDalquist> like if you store a portlet preference with an empty string value
[13:37:44 EDT(-0400)] <EricDalquist> the DB actually has something like '' in it
[13:37:50 EDT(-0400)] <EricDalquist> versus a null value actually stores null
[13:38:09 EDT(-0400)] <EricDalquist> luckily it is taken care of at the hibernate level through their custom type APIs
[13:38:21 EDT(-0400)] <EricDalquist> so we have a nullable-string type in our hibernate configs :op
[13:39:09 EDT(-0400)] <athena> (smile)
[13:43:22 EDT(-0400)] <dstn> so same thing happens on up_entity_type
[13:43:25 EDT(-0400)] <dstn> <index>
[13:43:25 EDT(-0400)] <dstn> <name>UPET_NAME_IDX</name>
[13:43:25 EDT(-0400)] <dstn> <column-ref>ENTITY_TYPE_NAME</column-ref>
[13:43:25 EDT(-0400)] <dstn> </index>
[13:43:25 EDT(-0400)] <dstn> <unique>
[13:43:26 EDT(-0400)] <dstn> <name>UPET_NAME_UNQ</name>
[13:43:30 EDT(-0400)] <dstn> <column-ref>ENTITY_TYPE_NAME</column-ref>
[13:43:32 EDT(-0400)] <dstn> </unique>
[13:43:49 EDT(-0400)] <dstn> well, not the same but related I guess
[13:45:59 EDT(-0400)] <EricDalquist> right
[13:46:03 EDT(-0400)] <EricDalquist> if there is a PK for that column
[13:46:10 EDT(-0400)] <EricDalquist> remove those two chunks
[14:03:12 EDT(-0400)] <EricDalquist> athena: I added a comments column to the table on the GSoC page
[14:03:26 EDT(-0400)] <EricDalquist> so you can more easily add your project-specific comment
[14:03:30 EDT(-0400)] <athena> ok i'll take a look
[14:44:11 EDT(-0400)] <EricDalquist> hey dstn once you get tables.xml fixed up can you commit it against that jira issue you opened?
[14:44:24 EDT(-0400)] <dstn> sure, one sec
[14:57:00 EDT(-0400)] <dstn> 45402 to trunk and 45403 to 3.1-patches
[14:57:15 EDT(-0400)] <EricDalquist> great, thanks!
[15:49:23 EDT(-0400)] <holdorph> eric what link did you use to apply to be the GSoC mentor. I think I filled out my account, but I didn't do anything 'mentor-wise' that I can tell
[15:50:18 EDT(-0400)] <EricDalquist> that's all I did too
[15:50:23 EDT(-0400)] <EricDalquist> I think Jim has to add us to the project now
[15:50:48 EDT(-0400)] <holdorph> ok, your email made it seem like you had done something more. ok, i'll reply back to jim
[16:03:19 EDT(-0400)] <athena> yeah, i just did the same
[16:03:23 EDT(-0400)] <athena> was like um . . . thasit?
[16:04:26 EDT(-0400)] <holdorph> maybe Eric can prove to jim that we don't have any other options to do more then that. (smile) like bringing him to his desk and saying "see.... i told you so"
[16:04:46 EDT(-0400)] <EricDalquist> ok (smile)
[16:07:29 EDT(-0400)] <athena> holdorph: forward the confirmation email? (smile)
[16:09:14 EDT(-0400)] <EricDalquist> so
[16:09:19 EDT(-0400)] <EricDalquist> just talked with jimh
[16:09:30 EDT(-0400)] <EricDalquist> at this poin he has submitted the organization app
[16:09:35 EDT(-0400)] <athena> ok
[16:09:51 EDT(-0400)] <EricDalquist> and he has to wait for that to be approved (looks like the 18th?) before we can be added
[16:09:58 EDT(-0400)] <EricDalquist> in the mean time, we should flush out the ideas page
[16:10:10 EDT(-0400)] <EricDalquist> because that is what google reviews while reviewing the organization
[16:13:34 EDT(-0400)] <holdorph> i don't see the ideas page referenced from the app page: http://socghop.appspot.com/org_app/show/google/gsoc2009/jasig_uportal
[16:15:41 EDT(-0400)] <dstn> EricDalquist, what is the difference between jexl and groovy? Or is it a matter of preference?
[16:17:22 EDT(-0400)]

<dstn> like this $

Unknown macro: {jexl(FNAME != null and FNAME != 'null')}

[16:17:35 EDT(-0400)]

<dstn> seems like it could just be $

Unknown macro: {groovy(FNAME != null)}

[16:17:56 EDT(-0400)] <dstn> but I'm not sure
[16:18:50 EDT(-0400)] <EricDalquist> jexl is slightly faster
[16:18:52 EDT(-0400)] <EricDalquist> but not as powerful
[16:18:59 EDT(-0400)] <EricDalquist> it is just an expression language
[16:19:03 EDT(-0400)] <EricDalquist> so single liners and stuff
[16:19:11 EDT(-0400)] <EricDalquist> groovy is a full scripting language
[16:19:14 EDT(-0400)] <EricDalquist> more powerful
[16:19:15 EDT(-0400)] <EricDalquist> but slower
[16:19:49 EDT(-0400)] <dstn> ok
[16:19:54 EDT(-0400)] <EricDalquist> oh and dstn, the changes you made for UP_ENTITY_TYPE in tables.xml
[16:19:59 EDT(-0400)] <EricDalquist> we should probably keep the index
[16:20:06 EDT(-0400)] <EricDalquist> er
[16:20:10 EDT(-0400)] <EricDalquist> keep the unique I mean
[16:20:36 EDT(-0400)] <dstn> k
[16:20:43 EDT(-0400)] <dstn> I can add it back
[16:21:09 EDT(-0400)] <dstn> well, actually...wait...isn't the primary key unique?
[16:22:27 EDT(-0400)] <EricDalquist> so on that table
[16:22:28 EDT(-0400)] <EricDalquist> <primary-key>ENTITY_TYPE_ID</primary-key>
[16:22:37 EDT(-0400)] <dstn> guess its possible to have 2 different primary keys with the same name
[16:22:40 EDT(-0400)] <EricDalquist> the problem was there was an index and a unique for <column-ref>ENTITY_TYPE_NAME</column-ref>
[16:22:46 EDT(-0400)] <EricDalquist> so different column
[16:23:03 EDT(-0400)] <EricDalquist> really what I should have done when extending tables.xml is just have an <index>
[16:23:12 EDT(-0400)] <EricDalquist> and have a unique="true" attribute on it :/
[16:23:19 EDT(-0400)] <EricDalquist> probably too late to make that big of a change though
[16:24:36 EDT(-0400)] <dstn> alright, well do u want me to add back the unique before I leave?
[16:24:49 EDT(-0400)] <EricDalquist> if you have time it would be much appreciated
[16:24:54 EDT(-0400)] <EricDalquist> sorry I didn't catch it earlier
[16:24:56 EDT(-0400)] <dstn> I read earlier that oracle creates a unique index to fulfill a unique constraint...
[16:25:02 EDT(-0400)] <EricDalquist> yeah
[16:25:09 EDT(-0400)] <EricDalquist> I just dug through the hibernate code
[16:25:17 EDT(-0400)] <EricDalquist> and it handles unique constraints for all DBs that way
[16:25:49 EDT(-0400)] <dstn> sweet
[16:27:50 EDT(-0400)] <dstn> also, I created http://www.ja-sig.org/issues/browse/UP-2355
[16:27:59 EDT(-0400)] <dstn> haven't looked at the solution yet, shouldn't be hard
[16:28:58 EDT(-0400)] <EricDalquist> ah yeah
[16:32:40 EDT(-0400)] <dstn> ok, unique constraint is back in trunk and patches
[16:34:43 EDT(-0400)] <EricDalquist> great, thanks dstn
[16:34:50 EDT(-0400)] <dstn> I only put it back on up_entity_types
[16:34:51 EDT(-0400)] <EricDalquist> its great having you committing stuff directly
[16:34:53 EDT(-0400)] <EricDalquist> yup
[16:35:12 EDT(-0400)] * dstn is scared to commit for these reasons
[16:35:21 EDT(-0400)] <EricDalquist> ah but you shouldn't be
[16:35:36 EDT(-0400)] <EricDalquist> I'm not going to just release some changes without being sure they are tested
[16:35:44 EDT(-0400)] <EricDalquist> and the worst that happens is trunk breaks for a little while
[16:35:55 EDT(-0400)] <EricDalquist> the great thing about version control ... we can always go back in time (smile)
[16:36:28 EDT(-0400)] <EricDalquist> I do know how you feel though ... I felt the same way when I first started committing uportal changes
[16:36:54 EDT(-0400)] <EricDalquist> and still feel that way when I get commit access to a new project
[16:37:32 EDT(-0400)] <dstn> well thanks for the encouragement
[16:42:35 EDT(-0400)] <EricDalquist> no problem (especially if it gets you to commit more (wink) )
[17:06:46 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[18:33:36 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[18:36:32 EDT(-0400)] <EricDalquist> he lennard1
[18:36:48 EDT(-0400)] <EricDalquist> you had mentioned some potential JPA performance enhancements at the conference
[18:36:56 EDT(-0400)] <EricDalquist> any chance of writing those up as a jira issue?
[18:51:19 EDT(-0400)] * tsnfoo (n=tsnfoo@cpe-65-24-108-125.columbus.res.rr.com) has joined ##uportal
[18:54:05 EDT(-0400)] <lennard1> sure, can do that tomorrow morning.
[18:54:18 EDT(-0400)] <EricDalquist> thanks, that would be great
[18:54:20 EDT(-0400)] <lennard1> I took a closer look and saw that the gains were likely to be minimal... so I dropped it
[18:54:30 EDT(-0400)] <EricDalquist> ah
[18:54:40 EDT(-0400)] <lennard1> I did not look at them all though
[18:54:44 EDT(-0400)] <EricDalquist> well it would still be interesting
[18:55:11 EDT(-0400)] <lennard1> right now I see a lot of places where we are making two calls to the db, where one would suffice
[18:55:24 EDT(-0400)] <EricDalquist> ah
[18:55:54 EDT(-0400)] <lennard1> had thought I saw an area where we would be looking at a serious N+1 problem... but upon closer examination I see that you had already forced the relationship to eager
[18:56:04 EDT(-0400)] <lennard1> so no worries on that one.
[18:56:22 EDT(-0400)] <EricDalquist> where was that?
[19:00:27 EDT(-0400)] <lennard1> @CollectionOfElements(fetch = FetchType.EAGER)
[19:00:55 EDT(-0400)] <lennard1> in PortletPreferenceImpl
[19:01:15 EDT(-0400)] <EricDalquist> ah
[19:01:39 EDT(-0400)] <EricDalquist> yeah, when I did the original code I knew we;d likely have a fair ammount of use of potentially detached objects
[19:01:50 EDT(-0400)] <lennard1> PortletPreferencesImpl too
[19:01:55 EDT(-0400)] <EricDalquist> so everything is supposed to be eagerly initializaed semi-coherently
[19:02:03 EDT(-0400)] <lennard1> also has an eager fetch in there
[19:02:19 EDT(-0400)] <EricDalquist> thinking that if you load a prefs object you will likely want each preference and its values
[19:02:27 EDT(-0400)] <lennard1> When you know it always should be eagerly fetched, that is a good way to go
[19:02:54 EDT(-0400)] <lennard1> generally the default is to let it all be lazy and then override with when you construct a query.
[19:03:03 EDT(-0400)] <lennard1> in this case though... think it is fine.
[19:03:17 EDT(-0400)] <EricDalquist> yeah
[19:03:37 EDT(-0400)] <lennard1> I also needed to do some digging to see what JPAs default behavior is for the one to one and many to one relationships
[19:03:49 EDT(-0400)] <EricDalquist> I think the only lazy associates we have are the parent-child relationships between things like a portlet definition and the child entities
[19:03:53 EDT(-0400)] <lennard1> those were the ones that a tweak to the query could yield some benefits
[19:03:59 EDT(-0400)] <EricDalquist> like:
[19:04:00 EDT(-0400)] <EricDalquist> //Hidden reference to the parent portlet definition, used by hibernate for referential integrety
[19:04:00 EDT(-0400)] <EricDalquist> @SuppressWarnings("unused")
[19:04:00 EDT(-0400)]

<EricDalquist> @OneToMany(mappedBy = "portletDefinition", targetEntity = PortletEntityImpl.class, cascade =

Unknown macro: { CascadeType.ALL }

, fetch = FetchType.LAZY)


[19:04:00 EDT(-0400)] <EricDalquist> private Set<IPortletEntity> portletEntities = null;
[19:04:39 EDT(-0400)] <lennard1> well... I think for most things default is lazy
[19:04:43 EDT(-0400)] <EricDalquist> that gets us the FK constraints without actually loading all of the children
[19:04:44 EDT(-0400)] <EricDalquist> ah
[19:04:55 EDT(-0400)] <lennard1> so where you have not explicitly defined it, it will likely be lazy
[19:04:55 EDT(-0400)] <EricDalquist> yeah there is actually no way in code to access that field
[19:05:30 EDT(-0400)] <lennard1> think there is one instance where JPA forces an eager all the time. Need to look that up
[19:05:43 EDT(-0400)] <lennard1> anyways... will look at it tomorrow and write a jira if necessary
[19:05:54 EDT(-0400)] <EricDalquist> thanks (smile)
[19:06:01 EDT(-0400)] <lennard1> I was looking for something that would make a huge difference... and did not come across anything in my first pass.
[19:06:12 EDT(-0400)] <lennard1> I did not look at the new stuff that drew wrote though.
[19:06:33 EDT(-0400)] <EricDalquist> yeah I gave it a bit of an overview
[19:06:37 EDT(-0400)] <EricDalquist> and it looks ok ...
[19:06:50 EDT(-0400)] <EricDalquist> but it is a self-referential tree structure
[19:07:08 EDT(-0400)] <EricDalquist> Obj 1->N Obj 1->N Obj .....
[19:07:24 EDT(-0400)] <lennard1> you said that in your performance tests related to the non drew JPA stuff, you saw something running a bit slower than you had anticipated?
[19:07:57 EDT(-0400)] <EricDalquist> I'm not sure I remember that
[19:08:08 EDT(-0400)] <EricDalquist> it may have been before we did all the fixing with JHU & Pearson
[19:08:25 EDT(-0400)] * lennard1 nods
[19:09:22 EDT(-0400)] <holdorph> Eric, on the 'mentorable projects' page, did you copy that from somewhere else to begin with?
[19:09:25 EDT(-0400)] <lennard1> ok... will look at the JPA stuff first thing in the morning. I did take an earlier pass, and didn't see anything that would result in a big gain, so did not figure the risk of a tweaking a query or two this close to GA was worth it.
[19:09:41 EDT(-0400)] <EricDalquist> the two I have my name on?
[19:09:59 EDT(-0400)] <EricDalquist> ah yeah lennard1 I'm thinking beyond the 3.1.0 release
[19:10:08 EDT(-0400)] <holdorph> I'm wondering if we should take out the sponsor/mentor column for the moment.
[19:10:08 EDT(-0400)] <EricDalquist> just wanted to make sure we didnt forget what we talked about in Dallas
[19:10:49 EDT(-0400)] <EricDalquist> holdorph: is it causing a problem?
[19:11:23 EDT(-0400)] <holdorph> well i was mostly interested in the history. jason's name is on there as a possible mentor but he's never edited that page
[19:11:55 EDT(-0400)] <EricDalquist> ah
[19:12:12 EDT(-0400)] <EricDalquist> JimH did the initial setup there
[19:12:19 EDT(-0400)] <EricDalquist> I do like your idea in the email though
[19:12:23 EDT(-0400)] <EricDalquist> I'll reply to that shortly
[19:12:24 EDT(-0400)] <holdorph> more broadly, i've sent an email to jim, but I wonder if we should be separating this into two pages
[19:12:25 EDT(-0400)] <holdorph> yup.
[19:12:36 EDT(-0400)] <holdorph> hmm.... thought your name was on the initial revision for that page
[19:12:58 EDT(-0400)] <holdorph> nm, confluence was only showing me the last few revisions
[19:13:25 EDT(-0400)] <holdorph> still don't see jason's name as a page editor on there though.
[19:13:52 EDT(-0400)] <EricDalquist> I'm not sure exactly where those came from
[19:13:57 EDT(-0400)] <EricDalquist> probably talking last year
[19:14:34 EDT(-0400)] <holdorph> do you jasig confluence admin ability?
[19:15:09 EDT(-0400)] <EricDalquist> yes
[19:16:02 EDT(-0400)] <holdorph> i forgot my password, I did the forgot password link, but didn't get the email, I thought i remember somewhere along the line that forgot password thing might not have been working
[19:16:26 EDT(-0400)] <holdorph> and obviously i lost my cookie that had me logged in (smile)
[19:16:33 EDT(-0400)] <EricDalquist> hah
[19:16:38 EDT(-0400)] <EricDalquist> ok ... just a minute
[19:47:37 EDT(-0400)] * lennard1 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[20:03:39 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[21:46:37 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined ##uportal
[21:54:01 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131712.dsl.bell.ca) has joined ##uportal
[23:19:10 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal
[23:21:17 EDT(-0400)] * jayshao (n=jayshao@ool-45731e0f.dyn.optonline.net) has joined ##uportal
[23:42:09 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined ##uportal