Re: second impl of metadata storage

11 Dec 2002 22:24:11 -0000 

Murray Altheim wrote:

No, I think all three are potentially a mix of both how metadata is
accessed and how it is stored. There seems to be two methods for
storage:

  1. within the database "record" itself, ie., as part of the stored
     content of an XML node,
  2. as a separate XML document


This looks to me more like an implementation detail.
[...] 

Again, I don't consider myself an expert on db design, but it seems
to me that there is a big difference. With metadata separate from
the stored document, you introduce performance and metadata-data
alignment issues. With metadata-in-wrapper, you introduce namespace
issues. Positively, with separate metadata there are no namespace
issues, you could potentially store multiple metadata instances.
For metadata-in-wrapper, metadata alignment is not an issue (if you
open a record, you have already opened its metadata). I don't think
of these as implementation details.

I haven't really thought about namespace issues, thanks for pointing me to that. This is actually a big issue with in-line metadata, if you are letting the user specify an XML snippet as metadata.

But again, I still tend to see that as implementation. We are debating about _storage_ here, and storage strategies aren't really an API level concern. Dave's implementation is separate, yet it can be easily seen from the external as in line. Yours is in line but it can be easily separated. You're right when you say:

It's just that once you commit to something that modifies
the basic core, it seems you're stuck with that methodology, so in
the end the API isn't really what's at issue -- you could write (as
you say) any number of APIs to that same metadata.

but then again the core can be modified at will, maybe even in a pluggable way. We have no user support, backward compatibility and the like, we are (a bit) more free to play.

BTW, I just remembered Tom Bradford saying in a previous post that Xindice actually *had* support for metadata internally, it just wasn't exposing them since there was no support in the API. I just read the source, and infact it seems like there is already a basic support inside the Record. If you look at org/apache/xindice/core/data/Record.java you will see:

public final class Record {
   public static final String CREATED = "created";
   public static final String MODIFIED = "modified";
   public static final String OWNER = "owner";
   public static final String GROUP = "group";

   private Key key = null;
   private Value value = null;
   private Map meta = null;
[...]
   /**
    * getMetaData returns metadata about the Value.
    *
    * @param name The property name
    * @return The metadata value
    */
   public Object getMetaData(Object name) {
      return meta != null ? meta.get(name)
                          : null;
   }
}

So well... this is another point to consider, isn't it?


I don't think so. Think about SQL/JDBC, where you are given a set of "standard" and basic metadata. If that's not enough for your application, you just glue some logic (more tables, triggers) so that you get what you're missing.
[...] 

Yes, that's the way I designed XNode: the "standard" metadata is
creation and modification date, which are stored as attributes,
whereas the name-value pairs are stored as property elements in
the XNode <xnode:Header> element, thus its extensibility.

We already debated this some time ago, didn't we? :-) I still think that a property based metadata system, while more simple and effective, isn't really "extensible". If you have complex metadata needs, the fact that you can put also a custom XML for further processing means, IMHO, that every need can be fullfilled (albeit with some effort). But I'm perfectly fine with basic metadata... actually I'd settle for *any* metadata ATM. :-)

Neither do I. This is why I really don't understand how did you manage to create an API implementation without touching the core. 

[...]


I'll tonight wrap up javadocs for both the API and the implementation
and get them onto the web so this won't be so mysterious. Basically,
since all the metadata is stored in the wrapper, I'm simply creating
or modifying it at the same time as I create or modify the record. I
have an XNodeStoreImpl object that manages the process. It's 48K of
Java code (with docs) so it's not that complicated.

Cool, let's debate that in front of the APIs so we will all have a chance to understand better what's going on.

Ciao,

--
Gianugo Rabellino

Reply via email to