...when JIRA is up :-)
On Fri, Jun 5, 2015 at 12:05 AM, Sean Busbey <[email protected]> wrote: > ASF mailing lists strip all attachments. If you want to reference something > you'll need to upload it somewhere and the include a link. > > Normally patches would go onto a filed JIRA to make licensing intention > clear. If the patch is trying to illustrate an approach but has known > limitations, a note to that effect is usually sufficient. > > -- > Sean > On Jun 4, 2015 7:26 PM, "dam6923 ." <[email protected]> wrote: > >> Hello! >> >> Thanks for all the support and direction thus far in my efforts to >> improve the system provenance record keeping. >> >> I'd like to propose a few changes to the ProvenanceEventRepository >> API. There are some inconsistent and error-prone method calls >> available that I think can be enhanced. >> >> I've based some of my ideas off of the Hibernate Session object that >> allows for this kind of plug-able behavior of persisting and searching >> objects. In general, I believe there should be a bigger overhaul down >> the road, but some items to consider for the shorter term: >> >> 1. Do not assume ProvenanceEventRecord objects have an ID of type >> long. Instead, I'd like to see the ID be "Serializable" so one can >> use numerical values, byte arrays (i.e., hashes), Strings (i.e., >> UUID). >> >> 2. Remove the method "getEvents". From what I can tell, the only >> place it is used is to generate the "Oldest event available" display >> on the Provenance UI. The way in which it is used is a bit wonky and >> not actually correct. The ControllerFacade assumes that the first >> item submitted to the repository is going to be the oldest. This >> isn't true. Since the client is responsible for setting the event >> date-time, the first item could have any arbitrary value and not >> actually the "oldest" event in a way that most users would expect. I >> would recommend removing this label from the UI altogether. It's >> value seems limited and is generated in this incorrect manner. >> >> 3. Add a "clear" method to allow the users to manually empty the >> repository. >> >> 4. Remove method "getMaxEventId". In an implementation that uses >> UUID/Hash ids, there is no such thing as a "max" ID. >> >> 5. Remove methods "registerEvent"/"registerEvents" in favor of a >> single "addEvent" that accepts a single ProvenanceEventRecord and >> returns its Serializable ID. >> >> 6. Introduce a ProvenanceEventRepositoryRuntimeException class (or >> something like that) instead of using explicit IO exceptions. As is, >> the IOException seems inconsistent across methods. >> >> I have attached a sample of these changes though only at the >> Interface, not all changes required. Changing to a Serialize object >> would affect several classes. >> >> Thanks. >>
