Timestamps are in GMT/BST.
[6:48] -asimov.freenode.net- *** Looking up your hostname...
[6:48] -asimov.freenode.net- *** Checking Ident
[6:48] -asimov.freenode.net- *** Found your hostname
[6:48] -asimov.freenode.net- *** No Ident response
[6:48] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:48] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:48] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[13:18] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:23] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) has joined #duraspace
[15:16] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[15:18] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) has joined #duraspace
[17:58] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) has joined #duraspace
[18:31] * eddies1 (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[18:32] * eddies (~eddies@cm102.epsilon176.maxonline.com.sg) has joined #duraspace
[18:32] * eddies (~eddies@cm102.epsilon176.maxonline.com.sg) Quit (Changing host)
[18:32] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[18:51] * fasseg (~fas@HSI-KBW-078-043-007-220.hsi4.kabel-badenwuerttemberg.de) Quit (Remote host closed the connection)
[19:54] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:58] * helix84 (a@195.113.97.174) has joined #duraspace
[20:00] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[20:00] <tdonohue> Hi all...welcome back after the holidays. It's time for our weekly DSpace Developers Mtg
[20:01] <tdonohue> agenda up at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-01-09
[20:01] <kompewter> [ DevMtg 2013-01-09 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-01-09
[20:02] <tdonohue> before we get started today...I did want to note that Joao has started some DAO implementation work (in case folks didn't see it)
[20:03] <tdonohue> I'd highly recommend we all take a few moments in the next week or so to look it over. I'm not sure we'll get to discuss it today, but I definitely want us to review it, in the hopes of getting some/most into 4.0 next year
[20:03] <tdonohue> See DS-1438 & Pull #161 for more info
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-1438 ] - [#DS-1438] DAO implementation - DuraSpace JIRA
[20:03] <mhwood> [2013 is now *this* year]
[20:04] <tdonohue> haha..yea, still getting used to that
[20:04] <tdonohue> "into 4.0 later THIS year"
[20:04] <tdonohue> Ok, but the main topic for today is the new JIRA workflow changes, which as mentioned (via email) are now in place: https://wiki.duraspace.org/display/DSPACE/JIRA+Workflow+Improvements
[20:04] <kompewter> [ JIRA Workflow Improvements - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/JIRA+Workflow+Improvements
[20:05] <helix84> Joao asked for help with the DAO work, too. I think it's mostly implementing the previously present methods in the DAO "style".
[20:06] <tdonohue> thanks, helix84. Yea, to reiterate, I definitely don't think DAO Implementation is something one person can do alone. We'd want to review Joao's work so far, and if we all want this in 4.0, we'd need to work together to make it happen
[20:07] <tdonohue> switching back over to JIRA Workflow stuff...as I mentioned via email, during our migration to the new Workflow setup, we had to revert some tickets back to "Received" state. Tickets in this state are essentially in our "backlog". We need to manually review them to move them on in the workflow (or close them, if they are now obsolete)
[20:08] <tdonohue> here's that backlog: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+status+%3D+Received+ORDER+BY+priority+DESC
[20:08] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+status+%3D+Received+ORDER+BY+priority+DESC
[20:08] <tdonohue> heli84 (thanks to him) already did a bit of work on the backlog...I've chipped in some too. It used to be at around 300 tickets, but is now down to 234.
[20:09] * mdiggory (~mdiggory@rrcs-74-87-47-118.west.biz.rr.com) has joined #duraspace
[20:09] <tdonohue> So, the big question is...how do we want to continue tackling this backlog. We could restart our "JIRA review" part of these meetings (and tackle this new backlog gradually), or we can all try and chip in more immediately and see if we can tackle it more rapidly in coming weeks
[20:10] <tdonohue> I'm sure there's other options out there too
[20:11] <helix84> I'd like to avoid us losing time on maintenance work during DevMtgs, the time here is scarce already
[20:11] <helix84> this can be mostly done individually
[20:11] <tdonohue> I think many/most could be done individually...though I'm sure there will be the occasional ticket that we feel needs some broader discussion in this mtg
[20:12] <hpottinger> maybe a bounty on work done on the backlog?
[20:12] <mdiggory> thank you helix84 and tdonohue for working on the backlog, that is actually a pretty good reduction
[20:13] <tdonohue> it's just a matter of us all making some effort though to review tickets individually (on our own)...either that, or we schedule a separate mtg to work together (in IRC) and just get through as much as we can manage
[20:13] <helix84> tdonohue: agreed, i skipped some (for the reason i told you today). the strategy i suggest is to cut down the number first by individual work and then maybe discuss the rest together.
[20:13] <mdiggory> the jira reviews are productive.
[20:13] <helix84> hi mdiggory, long time no see
[20:14] <mhwood> I think that helix84 is talking about RE-review of issues that had to revert to "received".
[20:14] <hpottinger> maybe designate a "backlog hour", a time of day where we show up in IRC to whittle away at this list?
[20:14] <helix84> mdiggory: see the log of the beginning of this meeting, I think you'll want to look at the mentioned DAO work
[20:14] <helix84> mhwood: right
[20:15] <tdonohue> yea, to mhwood's point, the "received" tickets are obviously now a mixture of "old, open tickets" (which likely already were reviewed and just need re-categorization), and "new, unreviewed tickets" (which need eyes and possible discussion).
[20:15] <helix84> hpottinger: how about starting with it one hour before the regular DevMtgs, that way we can discuss any results/doubts during the normal DevMtg with a wider audience
[20:16] <hpottinger> helix84, I'd be up with that, although I think that's Tim's office hours
[20:16] <mdiggory> also, lately, with workload, tracking all the activity can be challenging
[20:16] <mdiggory> having someone regularly go through and alert committers to tasks they maybe should be aware of would help keep things off floor
[20:17] <mdiggory> so a meeting beforehand might separate the wheat from the chaft
[20:17] <helix84> mdiggory: don't worry, i'm picking up the interesting bits for you ;) not all the xmlui bugs that need to be fixed :)
[20:17] <tdonohue> hpottinger -- that was what I was hinting at... some sort of "backlog hour" in IRC where we can try and decrease the list faster together (and it gives everyone the excuse of saying "Oh, sorry, got a meeting then"...though if you had something more important show up, no need to jump into the "backlog hour")
[20:18] <tdonohue> My "Office Hours" are essentially "null & void" :) No one ever really showed up....so, we can reuse that time as needed.
[20:18] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:18] <hpottinger> tdonohue, I think every work day would be great fun, actually
[20:18] <mhwood> If office hours and backlog hour conflict, we *do* have two channels....
[20:18] <tdonohue> (I still block off that "office hours" time on my own calendar just in case...so, I do have it free...no one just ever took me up on that yet)
[20:18] <tdonohue> mhwood -- very true
[20:19] <helix84> aschweer: welcome, please read about DAO in today's log: http://irclogs.duraspace.org/index.php?date=2013-01-09
[20:19] <kompewter> [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/index.php?date=2013-01-09
[20:19] <tdonohue> IRC backlog hour could be in #dspace. If anyone shows up for my office hours it happens in #duraspace.
[20:19] <hpottinger> I definitely think backload hour should be in the unlogged channel, yes
[20:20] <helix84> tdonohue: just as i imagined it :)
[20:20] <hpottinger> back-log, that is... ugh
[20:20] <hpottinger> have the loadregistries code in another window... curse these fingers
[20:20] <helix84> tdonohue: you should remind us of the backlog hour in your "DSpace Developers Meeting Today" emails ;)
[20:21] * tdonohue notes that btw -- if anyone of you ever did have something to discuss during my "office hours" timeframe...I'm still available. I just stopped advertising it though, as no one really showed up.
[20:21] <tdonohue> I'd be glad to change my email template for "DSpace Developers Meeting" to include backlog hour...
[20:22] <tdonohue> So, is that the approach we'd like to take then? "JIRA Backlog Hour" is Weds @19:00UTC in #dspace
[20:22] <helix84> for the record, i'm glad that you have the office hours, if only to know that it's time when you're available
[20:23] <helix84> +1
[20:24] <helix84> what about the half-hour of reviews during DevMtg? I'd keep it, mostly to look for volunteers.
[20:26] <tdonohue> We can still do some JIRA reviews during DevMtg. During the "Backlog Hour" we could identify tickets needing more discussion.. Eventually, once the "backlog" is whittled down, we could move JIRA reviews back to first 15-20 mins of DevMtg if we wanted.
[20:26] <tdonohue> So, the "Backlog Hour" may be a temporary meeting...once the backlog is essentially "gone" or much smaller, we can decide whether we still need that separate "Backlog Hour"
[20:27] <mhwood> Sounds like a plan.
[20:28] <tdonohue> Assuming others are in agreement? Gotten a bit quiet here in the last few minutes ;)
[20:28] <hpottinger> I do like the idea of using the office hours slot for this, functionally we'll actually be staffing the office (and not just Tim)
[20:28] <helix84> +1
[20:28] <tdonohue> hpottinger +1
[20:29] <aschweer> I'm not sure how often I can make it for that timeslot (8-9am here and I start work at 9am), but I like the idea
[20:29] <tdonohue> Ok. Done. We'll start this next week (and I'll add the reminder to my weekly mtg email). So, Jan 16 we'll have both a "Backlog Hour" (19:00UTC in #dspace) and "DevMtg" (20:00UTC in #duraspace)
[20:29] <tdonohue> aschweer -- understandable. no worries...we'll still bring the "important to discuss" tickets over to the DevMtg.
[20:30] <aschweer> thanks and I can always read the irc logs too
[20:31] <tdonohue> Ok. So, are there any other questions related to JIRA Workflow stuff in general? (I'd still encourage folks to individually categorize some tickets if you get the chance as well)
[20:32] <helix84> I just want to say that we can categorize all we want, but we also need to assign some issues and start working on them! :)
[20:33] <tdonohue> Oh...I forgot...on the agenda, I had noted that helix84 had asked me what to do about tickets that "need discussion" before they really can be categorized. It sounds like the appropriate thing to do is to bring them to the DevMtg for discussion. We also could tag/label them as "needs discussion" if they don't fit well into any other bucket yet.
[20:33] <tdonohue> helix84 -- yea, that too. Grab some tickets while you are at it ;)
[20:33] <hpottinger> just remember: whomever is looking at the backlog gets to pick all the interesting stuff :-)
[20:34] <helix84> about "needs discussion",
[20:35] <helix84> the new buckets we have are "needs details" (from reporter) and "needs volunteer". but some issues can't be immediately put into either bucket, because the suggestion just might be a bad idea. so we need to discuss whether we want to actually work on it (or how).
[20:36] <helix84> and we don't yet have a "needs discussion" Jira state, so the question was how to communicate this state (leave as "received", add a label or add a jira state)
[20:36] <tdonohue> To clarify -- "more details needed" can either mean we need more details from reporter OR we are setting the ticket aside cause we want feedback/use cases from DCAT.
[20:37] <helix84> tdonohue: that would work, but we need to cummunicate clearly who we're waiting on
[20:38] <tdonohue> helix84 -- yea, the expectation is that we add a comment to explain what details are needed
[20:38] <mhwood> Two targets :== two states / flag values
[20:38] <helix84> mhwood: there's still the current "received" state
[20:39] <tdonohue> well, we could essentially "tag" things as "DCAT" if we wanted to separate out "more details needed" from DCAT versus from the reporter
[20:39] <mhwood> IOW how do we ask Jira: which issues are waiting for discussion by developers?
[20:39] <mhwood> And the like.
[20:40] <mhwood> Jira, which issues are waiting for clarification from the submitter?
[20:40] <helix84> mhwood: good point, so it shouldn't be a comment
[20:40] <helix84> Siri, is my pizza here yet? :)
[20:40] <tdonohue> we can start using some tags for things like that. My goal is not to create tons of states...rather we could create some buckets and perhaps get more specific via tags/labels.
[20:41] <tdonohue> By "tags", I'm actually meaning "labels" : https://jira.duraspace.org/browse/DS#selectedTab=com.atlassian.jira.plugin.system.project%3Alabels-heatmap-panel
[20:41] <kompewter> [ DSpace - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS#selectedTab=com.atlassian.jira.plugin.system.project%3Alabels-heatmap-panel
[20:42] <tdonohue> For example, helix84 has been labeling some tickets as "has-patch" and "has-pull-request"
[20:42] <tdonohue> has-pull-request : https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+10100+AND+labels+%3D+has-pull-request
[20:42] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+10100+AND+labels+%3D+has-pull-request
[20:42] <tdonohue> We could do similar things for "needs-discussion" or "DCAT" or similar
[20:43] <tdonohue> this is just a brainstorm...feel free to disagree ;)
[20:43] <mhwood> We could. The point is to be able to get JIRA to help us sift them.
[20:44] <tdonohue> right...well, once something has a label in JIRA, you can create a query that says: JIRA, Show me all the tickets in the "more info needed" state, labeled "DCAT".
[20:44] <mhwood> The tags then explain (among other things) why an issue cannot advance.
[20:45] <helix84> so we'd agree to avoid a new Jira state. labels are one option. the other option is leaving it in the "received" state. are there any benefits/drawbacks of one approach over the other?
[20:45] <mhwood> If it's not in Received, what state would it be blocked in?
[20:46] <helix84> needs more info + needs-discussion/DCAT label
[20:47] <mhwood> OK. It's also useful to be able to filter "issues that have not been looked at". Current state diagram seems to say that Received state is that.
[20:49] <tdonohue> I'd suggest things needing more discussion by Committers could be: "Received" + "needs-discussion" label (It could remain in "Received" cause we don't know where to move it to yet & we just marked it as needing discussion in a DevMtg). Things needing discussion by DCAT could be: "Needs more Info" + "DCAT" label (as the Committers need more info from DCAT)
[20:50] <helix84> fine with me
[20:52] <tdonohue> that's just an idea... I always saw these "states" as referring to what the *Committers* need to proceed. So, "More Details Needed" means the Committers need more details (from someone)..."Volunteer Needed" means the Committers need a volunteer to work on it. "Accepted" means that a Committer has accepted the task & is starting work on it...etc.
[20:53] <tdonohue> But, I do agree that we may wish to clarify how we want to use these various "states". To avoid confusion and accidental mis-categorization
[20:53] <mhwood> Suggestion: actually consolidate more. Merge "needs details" and "needs volunteer" into "needs something". Add tags to say what it needs: DCAT attention, detail from submitter, volunteer, developer discussion....
[20:53] <aschweer> sorry, gotta run off to another meeting. bye all
[20:53] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[20:53] <mhwood> Issue goes to Accepted when it has everything it needs for someone to be working on it.
[20:54] <tdonohue> mhwood -- I actually thought about that..but then decided that I kinda liked the "More details needed" vs. "Volunteer needed" as it makes the status of the ticket more easy to understand to a layperson (DSpace community member / repo manager watching it)
[20:54] <mhwood> Ah
[20:54] <tdonohue> "Needs something" was just too vague
[20:54] <mhwood> "Blocked"
[20:55] <tdonohue> that's too negative sounding in my mind... but maybe it's just me
[20:56] <tdonohue> I also think that DCAT really likes the idea of the "More details needed" state, cause it lets them concentrate on a smaller segment of tickets a bit more easily
[20:56] <tdonohue> so, I'd be in favor of just leaving these states as-is, unless we had a very good reason otherwise....and just use labels to get more specific as needed.
[20:57] <helix84> fine with me
[20:57] <mhwood> It just seems like we're creating sub-states without a coherent design. An issue can be Received if nobody has seen it or if somebody decided that it needs discussion. Why isn't the latter a first-class state like Needs Volunteer?
[20:58] <mhwood> I don't see why some issues advance to a blocked state and others just sit where they are and are flagged to be blocked.
[20:58] <tdonohue> mhwood...well, the other option is to just send all "Needs Discussion" tickets to "More Details Needed" and label them as "needs-discussion" in that state.
[20:58] <helix84> mhwood: i'd say because we need to distinguish whose input we're waiting for, but not add too many states
[20:58] <helix84> similar situation as with has-patch/has-pull-request - not enough difference to grant a state, but useful to distinguish
[20:59] <mhwood> has-patch, has-pull-request are not mutually exclusive.
[20:59] <tdonohue> So, we could do: Tickets needing Committer Discussion -> "More Details Needed" + "needs-discussion" .... Tickets needing DCAT Discussion/feedback -> "More Details Needed" + "use-cases" OR "DCAT"
[20:59] <helix84> true
[21:00] <mdiggory> Before the end of the meeting time, I would like to point out the following proposal which was also presented to DCAT in the last meeting, they are reviewing it, and having committer feedback would be beneficial as well. https://wiki.duraspace.org/display/DSPACE/Proposal+For+Metadata+Enhancement
[21:00] <kompewter> [ Proposal For Metadata Enhancement - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Proposal+For+Metadata+Enhancement
[21:00] <helix84> but then neither are needs more details from submitter/DCAT/developers
[21:00] <mhwood> If an issue can have several attributes at the same time, they are not states. If an attribute excludes others, it's a state. Does that work?
[21:01] <helix84> mhwood: agreed. but we also want to avoid proliferation of states because it makes things hard to understand to the mentioned laymen
[21:01] <mhwood> Actually I'm arguing for *removing* a state and replacing it with a nonexclusive attribute.
[21:02] <mhwood> This issue can't proceed yet. It needs some subset of (detail, discussion, DCAT).
[21:02] <mhwood> Oops, (detail, discussion, DCAT, volunteer).
[21:03] <helix84> mhwood: that's what we had before this change - the Received/Open/Acceped states
[21:04] <tdonohue> Essentially, we've split "Open" into "More Details Needed", "Volunteer Needed" and "Accepted". So, one big bucket became three
[21:05] <tdonohue> I still prefer keeping "More Details Needed" separate from "Volunteer Needed". The Former means action is required *by someone else* (possibly non-Committer) before we can move forward. The latter means we just lack resources to move forward...so we can use it as a tool to try and get more Committers pulled in.
[21:06] <mhwood> Ah. I'm thinking of "sufficient information" as one of the resources. This may explain something.
[21:06] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has left #duraspace
[21:07] <tdonohue> mhwood -- it's not the same though...stuff in "Volunteer Needed" is essentially "ready to go"...we just need to track down a developer somewhere...and that's the stuff that we can encourage folks to "get their feet wet with" and possibly become newly nominated Committers
[21:07] <tdonohue> Whereas, the stuff in "More Details Needed" may be too big or "blue sky" to even dig into without much clearer use cases
[21:07] <mhwood> An issue could acquire a volunteer *before* it has enough detail or discussion or whatever.
[21:07] * jjjjj (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[21:08] <tdonohue> it could...but I'd argue it's harder to find a developer for stuff that's too "blue sky"... you need to find a real go-getter, who'd be willing to dig use cases out of others, etc.
[21:09] <tdonohue> anyways...that's my general thinking on these two states. If everyone else feels the other approach is better, we can try it. I just worry we'll get push back from DCAT & others who seemed to like the specificity of the state names
[21:09] <mhwood> OK, I've already made this take too long, I won't continue to press the point.
[21:10] <tdonohue> btw...I have to bow out now. I have another meeting coming up in 5 minutes, unfortunately
[21:10] <helix84> mhwood: honestly, i didn't understand what proposal you're making
[21:11] * tdonohue is heading off to another meeting....going into lurking mode. Will still check back later
[21:11] <KevinVdV> Needs to run until next week !
[21:11] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: KevinVdV)
[21:12] <mhwood> The proposal was: merge the "X needed" states, define tags to specify things that are needed, advance to Accepted when all the needs have been met.
[21:13] <helix84> i see. like i said, that's what we had before (sans the labels).
[21:14] <mhwood> I guess I mean that we needed the labels, not more states. That, and to work over the names of the states.
[21:14] * jjjjj (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:15] <mhwood> But I'm done arguing; I just didn't want to leave anyone wondering what I was even talking about. :-)
[21:15] <helix84> no problem
[21:20] <mhwood> Mulling over dim memories of discrete-event simulation or PERT charts or something. A transaction has to collect certain things to advance beyond this station....
[21:23] <mhwood> Hmmm, the issue's point of view is probably not the right one. It requires adding things that the issue doesn't care about. I'd better quiet down now and think.
[21:28] <mdiggory> One should generally consider taking a break when on starts to attribute human emotions such as caring to objects / data.
[21:28] <mhwood> Really? If objects have concerns, then they're concerned. :-)
[21:29] <helix84> that reminds me with kshepherd's "treat people as objects" quote in his presentation (+do not take human relationship advice from software developers)
[21:29] <hpottinger> I'd be concerned if an object had concerns
[21:29] <helix84> s/with/of/
[21:29] <kompewter> helix84 meant to say: that reminds me of kshepherd's "treat people as objects" quote in his presentation (+do not take human relationship advice from software developers)
[21:29] <mhwood> Maybe these are not human emotions, but mechanical emotions with human analogues.
[21:30] <helix84> OOP did some serious damage to your brain :)
[21:30] <hpottinger> bottle in front of me is preferred to a...
[21:31] <mdiggory> Do androids dream of electric sheep?
[21:32] <mhwood> If we instructed them to dream, maybe they would.
[21:32] <hpottinger> terrible book, wonderful movie
[21:36] <hpottinger> hey, helix84, you know how I was saying I'd like to try tinkering with the canonicalize method in DatabaseManager.java? Guess what? It already does exactly what I was thinking of doing...
[21:38] <hpottinger> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/DatabaseManager.java#L847
[21:38] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/storage/rdbms/DatabaseManager.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/DatabaseManager.java#L847
[21:40] <hpottinger> oh, wait, that's table names...
[21:40] <mhwood> Eww. canonicalize() (and a hundred other places) should be abstract, deferring to PostgresDatabaseManager, OracleDatabaseManager, etc. to provide the implementation.
[21:40] <hpottinger> mhwood++
[21:42] <tdonohue> see also DAO implementation work ;)
[21:42] <hpottinger> aha, https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/ColumnInfo.java#L152
[21:42] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/storage/rdbms/ColumnInfo.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/ColumnInfo.java#L152
[21:43] <tdonohue> (seriously, the DAO stuff from Joao is looking promising at a glance..and gets us out of the "if(Oracle)" ugliness in DatabaseManager and elsewhere...)
[21:44] <hpottinger> I intend to give the DAO stuff a serious looksee, as soon as I finish squishing this bug
[21:44] <tdonohue> is that your Oracle issue, hpottinger...just that ColumnInfo doesn't canonicalize() properly?
[21:45] <hpottinger> tdonohue: not sure, just going on a hunch, but figured it couldn't hurt to make the canonicalize "smart" about speaking Oracle
[21:45] <tdonohue> yep yep...well it's a promising hunch, considering the Oracle errors you are seeing all relate to "Column not found"
[21:46] <hpottinger> if that "fixes it" then I'll know that we're missing a canonicalize step somewhere
[21:47] <hpottinger> glad to see the exact logic I was thinking of using at https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/DatabaseManager.java#L847
[21:47] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/storage/rdbms/DatabaseManager.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/DatabaseManager.java#L847
[21:50] <mhwood> ColumnInfo.canonicalize() should just pass the buck to DatabaseManager.canonicalize()?
[21:55] <hpottinger> not sure about *should*, pretty sure I'm not qualified to answer.... but it doesn't
[21:56] <mhwood> That would do what I think you want, and avoid having two separate copies of identical ugliness.
[21:58] <hpottinger> Oh, this is just an experiment, aesthetics are of no concern, don't plan on committing this code anyway (famous last words, I know)
[22:04] <hpottinger> well... mhwood, I may have to do it your way after all... ColumnInfo does not have a handy isOracle flag...
[22:06] <mhwood> Bad enough that one of them does. I hope it works, but I've got to go.
[22:08] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:18] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[22:52] * tdonohue (~tdonohue@c-50-129-94-92.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:32] * mdiggory (~mdiggory@rrcs-74-87-47-118.west.biz.rr.com) has left #duraspace
[23:53] * helix84 (a@195.113.97.174) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.