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 <dtab...@gmail.com> 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



Reply via email to