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 15 Next »

[05:25:32 CST(-0600)] * esmhome_away (n=esm@esm.qis.net) has joined ##uportal
[08:09:33 CST(-0600)] * esm (n=esm@esm.qis.net) has joined ##uportal
[09:02:43 CST(-0600)] * esm (n=esm@esm.qis.net) has joined ##uportal
[09:07:43 CST(-0600)] * esm (n=esm@esm.qis.net) has joined ##uportal
[09:08:06 CST(-0600)] <esm> lol. I just used sed to munge a very large wiki page from my local wiki (smile)
[09:08:18 CST(-0600)] <EricDalquist> sounds like fun
[09:09:12 CST(-0600)] <esm> something i want to spend some time with - Doxia - the maven documentation parser/emitter has a confluence implementation
[09:09:22 CST(-0600)] <EricDalquist> hrm
[09:09:27 CST(-0600)] <EricDalquist> so it can output confluence markup?
[09:09:36 CST(-0600)] <esm> supposedly, i've never wired it up
[09:09:42 CST(-0600)] <esm> well
[09:09:50 CST(-0600)] <esm> i don't know if it emits
[09:10:01 CST(-0600)] <esm> but its there in Doxia
[09:10:18 CST(-0600)] <esm> i'd like to explore and see what its capabilities are
[09:12:18 CST(-0600)] <esm> i woudl fire up eclipse into my maven workspace
[09:12:26 CST(-0600)] <esm> is that sad - i have a workspace dedicated to maven -
[09:12:30 CST(-0600)] <esm> but my laptop would die
[09:12:41 CST(-0600)] <esm> fans fire up, the keyboard smokes
[09:12:47 CST(-0600)] <EricDalquist> lol
[10:15:00 CST(-0600)] * lescour (n=JBouncer@adsl-38-10-98.tulsaconnect.com) has joined ##uportal
[12:17:21 CST(-0600)] * esm (n=esm@clue.mse.jhu.edu) has joined ##uportal
[12:19:50 CST(-0600)] <EricDalquist> Hibernate needs to be able to read my mind (tongue)
[12:40:04 CST(-0600)] <esm> lol
[12:44:22 CST(-0600)] <EricDalquist> I'm trying to see if I can more accuratly model the uP3 OM in hibernate
[12:44:33 CST(-0600)] <EricDalquist> and I can store/get/update just fine
[12:44:56 CST(-0600)] <EricDalquist> its the deletes (specificly the cascading of the deletes) with the organization I want that is the problem
[13:06:20 CST(-0600)] <esm> i have no experience with cascading deletes in hibernate
[13:06:28 CST(-0600)] <esm> i've tried to stay away from that (smile)
[13:06:31 CST(-0600)] <EricDalquist> (smile)
[13:06:38 CST(-0600)] <esm> I have a big book on it though (wink)
[13:07:02 CST(-0600)] <esm> actually two books - hibernate in action - the first one, and then the second one, java persistance with ibernate which is like 3 times as thick and ihaven't read
[13:07:07 CST(-0600)] <EricDalquist> from my reading I'm pretty sure the answer I'm going to get is 'that isn't possible'
[13:07:18 CST(-0600)] <EricDalquist> I could probably do programmatic cascading deletes
[13:07:24 CST(-0600)] <esm> yeah
[13:07:34 CST(-0600)] <EricDalquist> but that isn't as effcient/clean as it just magically happening
[13:08:24 CST(-0600)] <EricDalquist> the real source of the problem is I only want references going from the leaves to the root
[13:08:44 CST(-0600)] <EricDalquist> and if I set my objects up that way hibernate has no idea what leaves to delete if I delete a node in the middle of the tree
[13:20:47 CST(-0600)] <EricDalquist> I'm really up in the air on what to do with this hibernate dao stuff
[13:22:17 CST(-0600)] <esm> so a node in the graph only has a reference down to its child?
[13:22:24 CST(-0600)] <esm> it currently doesn't have a reference to the parent?
[13:25:29 CST(-0600)] <EricDalquist> other way around
[13:25:38 CST(-0600)] <EricDalquist> a node in the graph only has a reference to its parent
[13:25:49 CST(-0600)] <EricDalquist> parents don't have collections of child node references
[13:26:13 CST(-0600)] <EricDalquist> so PortletDeployment <- PortletDefinition <- PortletEntity <- PortletWindow
[13:27:16 CST(-0600)] <EricDalquist> which works nicely for the most port
[13:27:18 CST(-0600)] <EricDalquist> part*
[13:27:27 CST(-0600)] <EricDalquist> except when I want to delete the PortletDefinition
[13:27:52 CST(-0600)] <esm> right
[13:27:52 CST(-0600)] <esm> ok
[13:27:55 CST(-0600)] <EricDalquist> it would be really neat if hibernate could find all the PortletEntities that reference the PortletDefinition and cascade the delete to them (which would do the same to the windows)
[13:28:06 CST(-0600)] <EricDalquist> but it can't because it has no way to know that information
[13:28:22 CST(-0600)] <EricDalquist> I making the relationships bi-directional is easy
[13:28:41 CST(-0600)] <EricDalquist> but has the side affect of loading a PortletDefinition loads the ENTIRE object tree under it into memory if we have lazy-loading off
[13:29:00 CST(-0600)] <esm> well why not turn lazy loading on?
[13:29:10 CST(-0600)] <esm> and override it when needed
[13:29:23 CST(-0600)] <EricDalquist> I was thinking about doing that
[13:29:39 CST(-0600)] <EricDalquist> I can even make the set/get for the parent to child collection private
[13:29:46 CST(-0600)] <EricDalquist> so only hibernate manipulates it
[13:29:49 CST(-0600)] <esm> right
[13:29:58 CST(-0600)] <EricDalquist> so it would never actually get loaded
[13:30:12 CST(-0600)] <EricDalquist> I'll play with that
[13:30:21 CST(-0600)] <EricDalquist> I have a little test project that I cloned the uP3 OM into
[13:30:45 CST(-0600)] <EricDalquist> I think I might end up scraping a bunch of our registry logic since Hibernate + 2nd level caching does exactly what we want the registries to do
[13:31:03 CST(-0600)] <EricDalquist> (note I would leave the interfaces and their usage)
[13:35:02 CST(-0600)] <esm> you don't persist anything to do with PortletWindow do you? Or do you...
[13:35:09 CST(-0600)] <EricDalquist> um
[13:35:20 CST(-0600)] <EricDalquist> I can't remember
[13:35:29 CST(-0600)] <esm> well besides being scary
[13:35:30 CST(-0600)] <EricDalquist> I think it can
[13:35:56 CST(-0600)] <EricDalquist> it is an option in the window manager
[13:36:10 CST(-0600)] <EricDalquist> because some folks want the portal to remember states/modes between sessions
[13:36:24 CST(-0600)] <EricDalquist> so I think we have windowState and portletMode properties on our IPortletWindow
[13:36:57 CST(-0600)] <EricDalquist> and there is a PortletWindow in the DB for every portlet every user has on their layout
[13:37:02 CST(-0600)] <esm> ok
[13:37:04 CST(-0600)] <EricDalquist> thats true for entities as well
[13:38:23 CST(-0600)] <esm> right i figured as much for entities.
[13:38:50 CST(-0600)] <EricDalquist> so thats where the concern about loading all this data into memory is ... that could be A LOT of objects for a large user base
[13:39:01 CST(-0600)] <esm> yes most definintly
[13:39:13 CST(-0600)] <esm> you might also, even if lazy loading is on, look at the fetch depth
[13:39:27 CST(-0600)] <esm> IIRC that controls how deep you go into the graph
[13:39:31 CST(-0600)] <EricDalquist> ah
[13:39:34 CST(-0600)] <EricDalquist> that would be handy
[13:39:51 CST(-0600)] <esm> I think that is a.... property on....
[13:40:07 CST(-0600)] <esm> i don't remember if it is a collection level property in the HBM mapping file or if that is a system property
[13:40:39 CST(-0600)] <esm> of course hibernate is pretty good about letting you override anything you want at run time when making a query
[13:41:03 CST(-0600)] <esm> some people in sakai use HQL plus named queries for more complex queries
[13:41:23 CST(-0600)] <esm> so you construct the query in HQL, give it a name, and put it in your HBM file.
[13:41:42 CST(-0600)] <EricDalquist> ah, the fetch_depth just limits the complexity of the joins, not the actual depth retrieved
[13:41:50 CST(-0600)] <esm> d'oh
[13:41:58 CST(-0600)] <esm> i thought there is something that controls depth

  • No labels