Timestamps are in GMT/BST.
[2:05] * kompewter (~kompewter@50.17.201.82) Quit (Ping timeout: 255 seconds)
[2:05] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (Ping timeout: 276 seconds)
[3:00] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[3:02] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (Remote host closed the connection)
[3:02] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[3:07] * kompewter (~kompewter@50.17.201.82) has joined #duraspace
[6:48] -adams.freenode.net- *** Looking up your hostname...
[6:48] -adams.freenode.net- *** Checking Ident
[6:48] -adams.freenode.net- *** Found your hostname
[6:48] -adams.freenode.net- *** No Ident response
[6:49] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:49] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:49] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[8:41] * kompewter (~kompewter@50.17.201.82) Quit (Read error: Connection reset by peer)
[8:41] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (Read error: Connection reset by peer)
[9:00] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[9:02] * kompewter (~kompewter@50.17.201.82) has joined #duraspace
[12:43] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[14:20] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Read error: Connection reset by peer)
[14:22] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[14:51] <DSpaceSlackBot> <tdonohue> Reminder that our DSpace DevMtg is in about 10 mins (15UTC) here. Our light agenda is at https://wiki.duraspace.org/display/DSPACE/DevMtg+2018-02-21
[14:51] <kompewter> [ DevMtg 2018-02-21 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2018-02-21
[15:00] <DSpaceSlackBot> <tdonohue> <here>: it's DSpace DevMtg time. See agenda above :point_up:
[15:00] <DSpaceSlackBot> <tdonohue> Let's do a quick roll call to see who's joining us today
[15:01] <DSpaceSlackBot> <tdonohue> (crickets) Looks like several of our usual suspects aren't here today yet.
[15:02] <DSpaceSlackBot> <tdonohue> Well, I'll post some general info here for anyone listening/reading....and we'll see if anyone else pops in.
[15:03] <DSpaceSlackBot> <tdonohue> As noted in the Agenda, the next DSpace 7 Mtg is tomorrow (15UTC). If you are curious about current status, this spreadsheet gives a high level status of what's done / in progress: https://docs.google.com/spreadsheets/d/18brPF7cZy_UKyj97Ta44UJg5Z8OwJGi7PLoPJVz-g3g/edit#gid=0
[15:03] <kompewter> [ DSpace 7 Development Planning - Google Sheets ] - https://docs.google.com/spreadsheets/d/18brPF7cZy_UKyj97Ta44UJg5Z8OwJGi7PLoPJVz-g3g/edit#gid=0
[15:04] <DSpaceSlackBot> <terrywbrady> sorry. here
[15:04] <DSpaceSlackBot> <tdonohue> Also, we have our next meeting of the DSpace Entities Group (see entities-wg channel in Slack) on Friday at 15UTC. Anyone interested in data modeling & improving how DSpace handles objects and metadata (in the future) may be interested to attend...or you can watch the recording which will be posted after the mtg
[15:05] <DSpaceSlackBot> <tdonohue> And, we have our first (ever) Developer Show & Tell meeting next Tues, Feb 27 at 16UTC (thanks to @terrywbrady). For more info see https://wiki.duraspace.org/display/DSPACE/DSpace+on+AWS%2C+Janitor+and+DSpace+-+Feb+27%2C+2018+at+1600UTC
[15:05] <kompewter> [ DSpace on AWS, Janitor and DSpace - Feb 27, 2018 at 1600UTC - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+on+AWS%2C+Janitor+and+DSpace+-+Feb+27%2C+2018+at+1600UTC
[15:06] <DSpaceSlackBot> <tdonohue> So, those three upcoming meetings are all good opportunities to contribute / and generally get more info on upcoming DSpace work. Plus the last two will be recorded
[15:06] <DSpaceSlackBot> <tdonohue> Anyone else joining us today, or is it just @terrywbrady and I? (and hi, @terrywbrady)
[15:07] <DSpaceSlackBot> <terrywbrady> hi @tdonohue
[15:08] <DSpaceSlackBot> <tdonohue> I'm hearing a whole lot of silence, so I don't think we have an official quorum of any sort. Not sure there's much we can achieve with just two of us here ;)
[15:09] <DSpaceSlackBot> <tdonohue> I will note though that the Code Style work is coming (soon). I've had a busy week full of too many surprises (small fires to put out)...so, I haven't gotten back to rebasing the big PR. But, I should today
[15:09] <DSpaceSlackBot> <tdonohue> Other than that, I don't have anything to share here.
[15:09] <DSpaceSlackBot> <terrywbrady> I owe @mwood a test of PR 1955.
[15:09] <DSpaceSlackBot> <terrywbrady> I am excited by the progress that I made running DSpace on Codenvy.
[15:10] <DSpaceSlackBot> <tdonohue> @terrywbrady: it sounds like great progress. A part of me wishes *you* were presenting at the Show & Tell next week. I'd love to see it
[15:10] <DSpaceSlackBot> <terrywbrady> @ptrottier gave the process a test and was able to replicate the experience. https://github.com/DSpace-Labs/DSpace-codenvy/blob/master/README.md
[15:10] <kompewter> [ DSpace-codenvy/README.md at master · DSpace-Labs/DSpace-codenvy · GitHub ] - https://github.com/DSpace-Labs/DSpace-codenvy/blob/master/README.md
[15:11] <DSpaceSlackBot> <terrywbrady> We will work it into an agenda soon.
[15:12] <DSpaceSlackBot> <terrywbrady> I suspect that there may be smarter ways to configure Docker to help things persist. (Currently a full rebuild is needed after every server restart.)
[15:12] <DSpaceSlackBot> <tdonohue> aha. Well, there's always ways to improve things later. First step is to just get it working at a basic level, and it sounds like you have
[15:13] <DSpaceSlackBot> <tdonohue> In any case, since it's still just the two of us, I'd recommend we simply cancel for today. I don't think there's anything we can accomplish alone. And, I can use this time to then get back to rebasing my massive code style PR: DSPR#1952
[15:14] <kompewter> [ https://github.com/DSpace/DSpace/pull/1952 ] - Align Java code with new Code Style by tdonohue ¡ Pull Request #1952 ¡ DSpace/DSpace ¡ GitHub
[15:14] <DSpaceSlackBot> <tdonohue> https://github.com/DSpace/DSpace/pull/1952
[15:14] <kompewter> [ Align Java code with new Code Style by tdonohue · Pull Request #1952 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/1952
[15:14] <DSpaceSlackBot> <terrywbrady> Sounds good. Can I sneak in one question? I posted a Jira bug about handle sequences after an AIP restore.
[15:15] <DSpaceSlackBot> <tdonohue> oh, yes, go ahead. I tried to answer that a bit on dev on Monday, but not sure I understood the issue fully
[15:15] <DSpaceSlackBot> <terrywbrady> Should the AIP command force an update of the handle sequence since this is a known point where the command could be needed.
[15:15] <DSpaceSlackBot> <tdonohue> DS-3844 is the ticket (for others listening)
[15:15] <kompewter> [ https://jira.duraspace.org/browse/DS-3844 ] - [DS-3844] Sequences are not updated by AIP RESTORE - DuraSpace JIRA
[15:15] <DSpaceSlackBot> <terrywbrady> Thanks for the reference.
[15:17] <DSpaceSlackBot> <tdonohue> I'm definitely not against the AIP command triggering a handle sequence update. However, it'd need to first figure out what database type you have, in order to run the proper `update-sequences.sql`... or we'd have to turn `update-sequences.sql` into a more easily call-able Java command (e.g. `dspace database update-sequences`)
[15:18] <DSpaceSlackBot> <terrywbrady> I just did a quick review of that ticket and I mention something that might be an additional bug (related to handle.additional.prefixes) introduced. I would need to compare 5x and 6x behavior side by side to be sure.
[15:18] <DSpaceSlackBot> <tdonohue> So, the idea is good...just would take some thought in how to implement it in a consistent manner.
[15:18] <DSpaceSlackBot> <terrywbrady> OK. I will grab the ticket.
[15:19] <DSpaceSlackBot> <tdonohue> `update-sequences.sql` is a sorta odd thing right now. When I implemented the Flyway DB stuff in Database (back in 5x.), I never had time to figure out how best to rework `update-sequences.sql`...and I ended up just leaving it alone
[15:19] <DSpaceSlackBot> <tdonohue> Sounds good
[15:19] <DSpaceSlackBot> <terrywbrady> Yeah. I see how that one will be tricky to work in with Hibernate.
[15:20] <DSpaceSlackBot> <terrywbrady> Would you call this ticket Minor or Major?
[15:21] <DSpaceSlackBot> <tdonohue> It's minor priority in my mind, as it's a known issue with documented workarounds (just run update-sequences). But, that doesn't mean I wouldn't still like it fixed/improved ;)
[15:21] <DSpaceSlackBot> <terrywbrady> Sounds good. Thanks for looking at that with me.
[15:22] <DSpaceSlackBot> <tdonohue> And definitely feel free to bring back ideas/brainstorms to this meeting. I'm glad to help brainstorm how to improve this. I'm still not sure myself whether there's ways we can turn this into a Java command, or if we just work with it how it is in a SQL script
[15:23] <DSpaceSlackBot> <terrywbrady> I would like for it to be automatic, but the command line option would be an improvement over the current process.
[15:23] <DSpaceSlackBot> <tdonohue> Personally, it might be nice to have it be a Java command, as it's easier to run using `dspace database update-sequences` than to figure out the `psql` equivalent. But, I'm not sure if that becomes harder with Hibernate, etc
[15:23] <DSpaceSlackBot> <terrywbrady> The 6.3 collection of tickets is actually becoming a substantial amount of fixes.
[15:24] <DSpaceSlackBot> <tdonohue> automatic is nice, but I don't think we'll be able to automate *every* scenario where this script is useful. So, I'd say it *has* to be a script that can be run manually...but if we can automate it in certain scenarios, that's great!
[15:25] <DSpaceSlackBot> <terrywbrady> Ah, this is the first time that I have needed it, but I can imagine there are other times where it becomes necessary.
[15:25] <DSpaceSlackBot> <tdonohue> Yes, 6.3 won't end up being all those tickets...I see that larger list as just a list of "things under possible review for 6.3". In all likelihood, 6.3 will be much smaller subset
[15:25] <DSpaceSlackBot> <hpottinger> heya, sorry, super distracted this morning, my kids had a delayed start due to the ice on the roads
[15:25] <DSpaceSlackBot> <hpottinger> he's been quiet during this meeting, but I'm pretty sure @tom_desair is lurking today
[15:26] <DSpaceSlackBot> <tdonohue> @terrywbrady: yes, update-sequences.sql is needed anytime sequences get out of sync. It doesn't happen much (usually during AIP restores, or manual Postgres database restores/migrations)...but it see it enough on mailing lists that I think we need to keep a way to run it manually for scenarios where it's needed.
[15:27] <DSpaceSlackBot> <terrywbrady> It would be nice to have the "dspace database repair" able to detect when it is needed.
[15:27] <DSpaceSlackBot> <hpottinger> yes, a script to run it would be a good first step and would let us document it instead of answering questions on th email list
[15:27] <DSpaceSlackBot> <terrywbrady> I added our chat notes to the ticket as a reference
[15:28] <DSpaceSlackBot> <tdonohue> @terrywbrady: that's a good idea, if it's "detectable" easily
[15:29] <DSpaceSlackBot> <hpottinger> detection could be as simple as seeing if the next handle actually would work
[15:29] <DSpaceSlackBot> <tdonohue> @terrywbrady: though it cannot be called "repair". We already have that script...`dspace database repair` already triggers a Flyway DB repair (which is perhaps not the best name...it doesn't 'repair' much, but just tells Flyway to ignore database migration checksum mis-matches)
[15:29] <DSpaceSlackBot> <tdonohue> but, some other name with the same concept would be great
[15:30] <DSpaceSlackBot> <terrywbrady> Good info. I forgot that is the context for "repair"
[15:31] <DSpaceSlackBot> <tdonohue> @hpottinger: it's not just correcting handle sequences though. It corrects *all sequences*. Handles are the most likely to go awry
[15:31] <DSpaceSlackBot> <hpottinger> and the error message that is sent if the handle can't be made could be changed to suggest running the update sequences script
[15:32] <DSpaceSlackBot> <hpottinger> I wonder if we could just make sequences self-healing?
[15:32] <DSpaceSlackBot> <tdonohue> @hpottinger: hmm...possibly.
[15:32] <DSpaceSlackBot> <terrywbrady> @hpottinger, that is an interesting idea
[15:32] <DSpaceSlackBot> <sulfrian> It should be easy to detect: You could check, if the max value of the id is less than the value of the sequence.
[15:33] <DSpaceSlackBot> <tdonohue> You know what... we might be able to turn this into a Flyway *callback script* that is triggered anytime you start up Tomcat
[15:33] <DSpaceSlackBot> <hpottinger> @sulfrian is right, that's how the update sequences SQL actually works
[15:33] <DSpaceSlackBot> <terrywbrady> that would simplify the hibernate issue
[15:34] <DSpaceSlackBot> Action: hpottinger is starting to get pretty excited about 6.3 now
[15:37] <DSpaceSlackBot> <tdonohue> Flyway callback scripts can be setup to run either before or after Flyway triggers...we have a few of them already: 1) Here's one that checks for "pgcrypto" to be installed in Postgres (as it's required for DSpace 6.x): https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/PostgreSQLCryptoChecker.java 2) Here's one that updates the metadata / bitstream format registri
[15:37] <DSpaceSlackBot> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/DatabaseRegistryUpdater.java 3) Here's one that creates the Admin/Anon groups if they are missing: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/GroupServiceInitializer.java
[15:37] <kompewter> [ DSpace/PostgreSQLCryptoChecker.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/PostgreSQLCryptoChecker.java
[15:37] <DSpaceSlackBot> <hpottinger> I spent my Presidents Day holiday working on DSpace stuff... but that's probably the biggest block of volunteer time I'm going to have for a while
[15:37] <kompewter> [ DSpace/DatabaseRegistryUpdater.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/DatabaseRegistryUpdater.java
[15:37] <kompewter> [ DSpace/GroupServiceInitializer.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/storage/rdbms/GroupServiceInitializer.java
[15:37] <DSpaceSlackBot> <tdonohue> So, hypothetically, we should be able to have a Flyway Callback that checks each sequence...and if it's out-of-date, updates it.
[15:38] <DSpaceSlackBot> <hpottinger> let's make a ticket for that
[15:38] <DSpaceSlackBot> <tdonohue> And this could be triggered either before or after Flyway runs...it's up to us
[15:39] <DSpaceSlackBot> <hpottinger> at Servlet startup is probably the best time for sequence surgery
[15:40] <DSpaceSlackBot> <tdonohue> Technically this would trigger whenever Flyway is triggered. Flyway gets triggered at servlet startup, but also when you run certain CLI tools (those that need a database connection). Essentially, Flyway is triggered on the first connection to the database
[15:40] <DSpaceSlackBot> <terrywbrady> I was imagining that we would re-write each sequence to do a smarter calculation...
[15:41] <DSpaceSlackBot> <terrywbrady> Perhaps that would not perform welll.
[15:42] <DSpaceSlackBot> <tdonohue> I'm not sure what you mean by that, @terrywbrady. I think we need these sequences...we don't want to change all our queries to have to find the new "max(handle)" every time we assign a new handle. That would degrade performance over time, as more and more handles are added...finding the "max" would take longer and longer
[15:42] <DSpaceSlackBot> <tdonohue> But, I think updating these sequences when they are wrong can be done via a Flyway Callback, or similar
[15:43] <DSpaceSlackBot> <terrywbrady> That was my first imagining from Hardy's suggestion for "self-healing" but I agree that could be a performance issue.
[15:43] <DSpaceSlackBot> <sulfrian> The handle stuff is currently doing a regex_replace on every handle. I do not know if it performs so well, that we want to execute on every startup.
[15:44] <DSpaceSlackBot> <tdonohue> @sulfrian: good question. I'm not sure myself... we'd have to test it.
[15:44] <DSpaceSlackBot> <sulfrian> (Would be easier if the handle would be stored in two columns.)
[15:44] <DSpaceSlackBot> <tdonohue> But, yes, the Handle sequence is a much more complex query to update: https://github.com/DSpace/DSpace/blob/master/dspace/etc/postgres/update-sequences.sql#L71
[15:45] <kompewter> [ DSpace/update-sequences.sql at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/etc/postgres/update-sequences.sql#L71
[15:46] <DSpaceSlackBot> <tdonohue> Perhaps we could look into a way to "detect" if the handle sequence needs an update (one that may be better performing), before we'd run this update. But, I'm not sure off the top of my head what that'd be
[15:47] <DSpaceSlackBot> <tdonohue> To me though, it seems like the other 10-15 sequences are easier to script into a Flyway callback. The Handle sequence likely could be...but may take a bit more thought
[15:47] <DSpaceSlackBot> <sulfrian> If the handle suffix would be in its own BIGINT column, it would be the same query like the other sequences.
[15:48] <DSpaceSlackBot> <tdonohue> @sulfrian: yes, but that's a more complex change...it's a database migration that'd need to happen in a major release
[15:48] <DSpaceSlackBot> <terrywbrady> Not all handles in a repo have the same prefix
[15:48] <DSpaceSlackBot> <sulfrian> @tdonohue Yes. I know.
[15:48] <DSpaceSlackBot> <sulfrian> @terrywbrady You would need two columns. One for the prefix and one for the suffix.
[15:50] <DSpaceSlackBot> <tdonohue> In general, it sounds like we've generated some good ideas here to start moving forward. There's some questions about the handle prefix updates that might take more digging / performance testing for large numbers of handles.
[15:50] <DSpaceSlackBot> <terrywbrady> I will add the rest of this conversation into 3844.
[15:50] <DSpaceSlackBot> <terrywbrady> I have claimed the ticket, but I would be delighted to relinquish it if someone else is ready to get started
[15:51] <DSpaceSlackBot> <tdonohue> And I think it'd be very doable to script this into both a CLI tool (`dspace database update-sequences`) and a Flyway Callback, if we felt there's still a need to run it manually. You'd just create the CLI tool, and have a Flyway Callback call its methods via Java.
[15:52] <DSpaceSlackBot> <tdonohue> But, I'm not sure we'd need both...it really depends on whether we feel we can automate the handle sequence updates via Flyway. If the performance isn't great, we may need to leave that out of Flyway and provide a manual way to run it / automate it only for certain scenarios (like AIP restore)
[15:54] <DSpaceSlackBot> <hpottinger> you know, our startup isn't exactly speedy anyway, I think we can handle a bit more lag on startup
[15:55] <DSpaceSlackBot> <tdonohue> Ok, well, good discussion after a "canceled" meeting. Thanks @terrywbrady, @hpottinger and @sulfrian;) As we are nearly at the hour, I'm not going to bring up any other topics
[15:55] <DSpaceSlackBot> <terrywbrady> Good discussion... even if we did not get dismissed early.
[15:56] <DSpaceSlackBot> <tdonohue> @hpottinger: depends entirely on how much "a bit more lag" it is ;) For small sites, it likely wouldn't be noticeable. But, once you get up to hundreds of thousands (or millions) of Handles (and remember, Communities/Collections also get Handles), then we'd need to make sure the "lag" doesn't turn into minutes
[15:57] <DSpaceSlackBot> <hpottinger> it's easy to find a max
[15:57] <DSpaceSlackBot> <tdonohue> It's something that should be testable though... generate a large number of handles...and see how this query performs
[15:57] <DSpaceSlackBot> <tdonohue> @hpottinger: no, not with Handles. Look again: https://github.com/DSpace/DSpace/blob/master/dspace/etc/postgres/update-sequences.sql#L71
[15:58] <kompewter> [ DSpace/update-sequences.sql at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/etc/postgres/update-sequences.sql#L71
[15:58] <DSpaceSlackBot> <tdonohue> @hpottinger: the concern is that "regex_replace" *on every handle*
[15:58] <DSpaceSlackBot> <tdonohue> when you start running millions of regexp_replace calls, I'm not sure how well that'll perform
[15:59] <DSpaceSlackBot> <tdonohue> *all* the other sequences though are simple "max()" calls...those should be fine. It's only the "handle_seq" that could have performance issues
[16:00] <DSpaceSlackBot> <hpottinger> hmm... perhaps an opt-out configuration
[16:00] <DSpaceSlackBot> <hpottinger> I think there was a similar concern for something else Flyway does every time Tomcat starts
[16:00] <DSpaceSlackBot> <tdonohue> I think we need to simply test it first. See what the performance implication is. We're guessing right now.
[16:02] <DSpaceSlackBot> <tdonohue> The other concern was with the automatic Solr reindex that Flway triggers *only after a database change is made*. That obviously has performance issues as you are reindexing everything...but it's necessary for certain types of DB changes.
[16:02] <DSpaceSlackBot> <tdonohue> But, that's a different scenario than this Handle Seq. So, it's a bit off topic ;)
[16:03] <DSpaceSlackBot> <tdonohue> In any case...I'm heading into lurking now. I want to get to rebasing my code style PR
[16:03] <DSpaceSlackBot> <tdonohue> thanks again all for the good discussion / ideas
[16:03] <DSpaceSlackBot> <hpottinger> right I'm thinking if we make an opt-out option for the sequence update that it'd be easy enough to add an opt-out option for the reindex
[16:05] <DSpaceSlackBot> <tdonohue> @hpottinger: There's already an "opt out" for automatic reindex. It's not simple yet though...but it's documented in step #11 of the upgrade process (see yellow note in that step): https://wiki.duraspace.org/display/DSDOC6x/Upgrading+DSpace
[16:05] <kompewter> [ Upgrading DSpace - DSpace 6.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC6x/Upgrading+DSpace
[16:05] <DSpaceSlackBot> <sulfrian> Maybe we should try to split up the handle for DSpace7?
[16:05] <DSpaceSlackBot> <terrywbrady> We have 1million handles. If I run the max/regex query it is taking about 2 sec.
[16:05] <DSpaceSlackBot> <tdonohue> @terrywbrady
[16:07] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[16:09] <DSpaceSlackBot> <tdonohue> @sulfrian: not against it...but I admit I haven't analyzed it enough to see if it'd truly be that simple. That said, the DSpace 7 effort is already rather large, and I'm not jumping to throw more tasks into that release, unless someone is volunteering for them and taking them on (and we verify they don't slow down other parallel efforts) ;)
[16:10] <DSpaceSlackBot> <tdonohue> I will also note that (for some time now) there have been discussions about making DSpace _less tied_ to Handles (i.e. making its identifier scheme a bit more configurable to also support DOIs, or other external identifiers). So, this might be fixed as part of that...but I'm not sure that effort will occur until DSpace 8 at the earliest
[16:11] <DSpaceSlackBot> <hpottinger> oh, hey, speaking of DSpace 7, Open Repositories 2018 registration is open, and there are a couple of DSpace 7-related workshops you can sign up for
[16:11] <DSpaceSlackBot> <hpottinger> I've registered and I'm signed up for the REST-API workshop in the afternoon
[16:11] <DSpaceSlackBot> Action: tdonohue heading into "lurking" for real this time. I'll be around, but getting back to my Code Style PR now
[16:11] <DSpaceSlackBot> <terrywbrady> Have a good day everyone
[16:13] <DSpaceSlackBot> <terrywbrady> If anyone has spare time for testing, the following 4 PR's could be tested in one session: https://github.com/terrywbrady/restReportTutorial/blob/master/README.md
[16:13] <kompewter> [ restReportTutorial/README.md at master · terrywbrady/restReportTutorial · GitHub ] - https://github.com/terrywbrady/restReportTutorial/blob/master/README.md
[16:49] <DSpaceSlackBot> <mwood> Sorry I missed the meeting. Do we have any notion of *why* sequences get out-of-sync? Could we just *fix the problem*?
[16:51] <DSpaceSlackBot> <tdonohue> @mwood: unfortunately, no. The primary scenarios are handles sequences getting out of date after AIP restoration (as AIPs can be restored in a relatively random order). But this has come up in other odd scenarios on mailing lists in past...sometimes after migrating databases (IIRC)
[16:52] <DSpaceSlackBot> <tdonohue> But, this `update-sequences.sql` script has been around forever. We could search the email archives for every time it is mentioned...but, I'm not sure how informative that'd be overall
[16:57] <DSpaceSlackBot> <mwood> So the underlying issue, for Handles at least, is that Handles are sometimes assigned by sequence and sometimes by an external source. The Sequence doesn't know everything that is going on.
[17:01] <DSpaceSlackBot> <mwood> I wonder what would be the cost of a stored procedure and a trigger on the sequenced column? When inserting a row, compare the sequence to max(that column) [which should be really cheap -- it should be in one of the index pages already]. If the sequence is stale, set it to max+1 and continue. Dunno how feasible this is -- I've never yet worked with either stored procedures or triggers.
[17:03] <DSpaceSlackBot> <mwood> update-sequences.sql always felt like a kluge that we should get rid of someday.
[17:06] <DSpaceSlackBot> <tdonohue> @mwood: yes, it's worth analyzing. I'm just not yet confident enough to say we can get rid of update-sequences altogether. (Though, I too wish we could get rid of it)
[17:11] <DSpaceSlackBot> <mwood> One other brainstorm, before I shut up: stop using serial numbers for Handles. Generate a UUID, BASE64 encode it for brevity, and retry on collision.
[17:12] <DSpaceSlackBot> <mwood> Sequences are cheap, but we may be abusing them.
[17:13] <DSpaceSlackBot> <tdonohue> @mwood: good point. UUIDs are something we didn't have before, so it forced us somewhat into sequences. We do have an opportunity to rethink that approach
[22:02] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:48] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.