I lean towards B as well. The interesting question is how to succinctly store the dependency field information in this catalog, i.e. I have these fields which correspond to the primary key fields of this other metadata dataset. Steven
On Wednesday, October 12, 2016, Mike Carey <[email protected]> wrote: > Got it. IMO option B) is probably "better" in the sense that it seems > "safer" and "more transparent". With A) not much might be known about why > those catalog entries are there, assuming a generic notion of "entity", and > there's always the potential for a buggy extension to forget to delete a > dependency and therefore force the non-deletion of a given dataverse. With > B) you know what the issue is - the supposed existence of a metadata > dataset - and you have the possible recourse of verifying the existence of > such a dataset. (E.g., if a buggy extension drops its dataset but forgets > to update this registry, you can at least discover manually that the > dataset is already gone.) Maybe not a big deal, but.... > > > On 10/12/16 3:11 PM, Steven Jacobs wrote: > >> Yes, "catalog" would be the better word here. Thanks for the >> clarification. >> >> Steven >> >> On Wed, Oct 12, 2016 at 12:38 PM, Mike Carey <[email protected]> wrote: >> >> I assume that by "index" you really mean "catalog" (as opposed to index in >>> the physical sense)? I.e., your two proposals are about a possible >>> additional metadata dataset in support of extension dependency >>> management? >>> >>> >>> On 10/12/16 9:47 AM, Steven Jacobs wrote: >>> >>> Hi, >>>> I am trying to get feedback from the group in general about how best to >>>> add >>>> Metadata Dependencies, particularly in the context of extensions. The >>>> functionality that is needed is as follows: >>>> >>>> *When dropping a metadata entity A (e.g. a dataverse), first check >>>> whether >>>> A has any metadata entities that depend on it. Then allow these entities >>>> two options:* >>>> >>>> *1) block: don't drop A while this dependent entity exists* >>>> *2) chain: when dropping A, drop this dependent entity as well.* >>>> >>>> One issue to keep in mind here is that with extensions, Asterix will not >>>> currently know about metadata datasets added by extensions. >>>> >>>> So far we have two proposals for this issue: >>>> >>>> A) Metadata dependency index. When you create an entity that depends on >>>> another, add an entry to this index. Check this index when dropping an >>>> entity. >>>> >>>> B) Metadata data set index. All Metadata datasets would be registered in >>>> this index, and then we can query them as needed when dropping an >>>> entity. >>>> In this case we would need some way to specify which fields in these >>>> datasets represent dependencies in order to query them properly. >>>> >>>> We would like any feedback on these two solutions or proposals for >>>> alternate solutions. >>>> >>>> Steven >>>> >>>> >>>> >
