Metadata

Understanding Metadata

YapDatabase supports storing both an 'object' & 'metadata' for every (collection, key) tuple.

func setObject(_ object: Any?, forKey key: String, inCollection collection: String?, withMetadata metadata: Any?)

In other words, the underlying database table has a dedicated column for metadata:

| collection(text) | key(text) | object(blob) | metadata(blob) |

In contrast to the 'object', metadata is completely optional. That is, if you attempt to store a nil 'object' to a row, then YapDatabase will delete that entire row. If you attempt to store a nil 'metadata' to a row, that's entirely OK.

Some people have no use for metadata. Others rely heavily on it. Both are supported by YapDatabase, and your own usage is entirely a product of your application's needs.

 

Motivation

So when would one use metadata? What is it good for?

Simply put, the metadata field allows you to store extra information that may not be included in the object itself. A concrete example may be instructive.

Let's say your application is downloading JSON objects from a server and storing them in the database. There's just one problem. You also want to store the date the object was downloaded. This will allow you to see if the object is stale, and should be refreshed from the server. But you really don't want to force this information into the object. It's not part of the JSON, and forcing it to become part of the object just doesn't feel right. Enter metadata !

Since each row has an extra metadata column, you're free to store whatever you like right next to the object within the database. So you might simply store the download timestamp. Or maybe you get more advanced, and you store both the download timestamp & the eTag (to make refreshes even faster)!

Again, there's absolutely no requirement that you store this information within the metadata column. You could just as easily add these properties directly to the object itself. It all has to do with your preferences & existing architecture.

Other examples:

• You're dealing with existing legacy classes, and it's a pain to change them.
• You're getting your objects from a 3rd-party framework, and it's not really possible/desirable to change them.
• It's impossible to change the objects. (E.g. you're storing raw images in the object column)

And when this happens, metadata comes to your rescue.