Time/Place
This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:
- Time: 11:00am Eastern Daylight Time US (UTC-4)
- Audio/Video Conference Link: https://lyrasis.zoom.us/my/fedora
- Dial-in:
+1 408 638 0968
+1 646 876 9923
+1 669 900 6833
Meeting ID:
812 835 3771
- Dial-in:
Join fedora-project.slack.com on the "tech" channel
Attendees
- Danny Bernstein
- Jared Whiklo
- Ben Pennell (out)
- Andrew Woods
- Peter Winckles
- David Wilcox
- Ben Cail
- Daniel Lamb (out)
- Bethany Seeger (out)
- Aaron Birkland
- Thomas Bernhart
Agenda
- Announcements
- ...
- April Sprint Planning
- Fedora and Docker
- Mystery solved: https://hub.docker.com/u/fcrepo
- Merging: https://github.com/fcrepo4/fcrepo4/pull/1646 ?
- Containment Index
- How to handle SQL differences (H2, MySQL, PostgreSQL) - pluggable connectors?
- In-flight
- ??
- To review:
- Approved by Peter Winckles... need merge from any committer
- Noting that if multiple Mementos are created within the same second, only the most recent is retrievable
Tickets
In Review
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
Notes
Announcements
- Sprint starts the first Monday of April
- Careful of Internet trolls joining zoom meetings, going to try to disable screen sharing except for host on lyrasis zoom by default
- Have noticed that strange usernames have joined at odd hours, so watch out
Sprint Planning
- Kudos to Jared for containment index PR, it has moved us forward in a big way.
- Looks like lots of functionality is now starting to work because of this.
- Let's consider broadening the scope of the April sprint as a result. Even the UI work
- Required a bit of learning about JDBC templates. Are we OK using a RDBMS, using the proposed structure?
- There are tables that are tracking adds and deletes, there's no SQL transaction going on. Those tables that are monitoring the changes are merged into the containment at the end, after having been recorded in the JDBC transaction.
- This is done in order to handle multi-request and long-lasting transactions. Is it appropriate to keep a JDBC transaction open over all this time
- Index the whole ID as a primary key? There are pros and cons, Maybe we should use a hash of the ID? Assume field length is 255 characters. Lookup table from ID to int?
- Came across issues related to differences between SQL implementations.
- There are tables that are tracking adds and deletes, there's no SQL transaction going on. Those tables that are monitoring the changes are merged into the containment at the end, after having been recorded in the JDBC transaction.
- Even if we make changes to approach, this PR is valuable. API is fine, triple service is fine, etc. At least two other people should take a look, but this will move us forward even if we make changes later.
- Open question: should you be able to read the index without some sort of transaction ID?
- Transactions need testing. Not sure if long-running transactions actually work
- Action: Danny Bernstein create JIRA for remaining transaction work. Most of the infra is in place, it's just a matter of coordinating it in the http layer.
Actions
- Who: Clarify in in documentation that multiple simultaneous writes to OCFL are not supported
- Who: After team has a chance to comment, send Ghost Node idea to general community for feedback
- Danny Bernstein to call Docker about fcrepo account
- Danny Bernstein to email Community list about fcrepo DockerHub account