query and get do not return key of stored item

[lordnull]

It can be useful to know what key an item was stored in to make later retrieval easier, as well as allow for reference by other objects. Perhaps stored as a '_key' property, or using an interal '_id' property.

It may be useful to store objects wrapped to allow meta data to avoid needing to dictate any form of structure upon the stored data.

[Morgul]

I'm of two minds about this. First, if we wrap the object, there's then an additional step required in retrieval, always. I don't like that (as it's removing the dead simple nature of using this.

However, if we force _id (or the like) we're messing with the user's object, and I'd rather avoid that as well.

There's a couple of points. When doing a get, you always have the key. There's no way to retrieve the object without knowing key. You don't know any additional metadata, but until we have any other metadata to store, it's a moot argument.

For the return value of query... it's possible we could return a QuerySet object (that inherits array's prototype). That object would have some additional functions for pulling items out. Internally, it would be wrapped in an object that contained metadata and the value. It would allow for retrieving the value and metadata.

I still don't like it. Any other thoughts?

[Morgul]

After sleeping on this, I've settled on a proposal:

---

Metadata Support

When you store an object in Dustbin, it adds a single key to the object: $metadata. Currently, Dustbin's metadata looks like this:

{
    key: "some_key",
    bin: "some_bin",
    created: "Tue Apr 15 2013 23:05:42 GMT-0500 (CDT)",
    updated: "Tue Apr 16 2013 09:01:38 GMT-0500 (CDT)"
}

You may feel free to read this data and use it how you see fit, however, changes to the metadata do not propagate, even if you store the object after changing it.

---

I think this is a fair compromise, and (hopefully) the least likely to cause issues with people storing things. It also means that I can then support this:

// Store an object previously retrieved without passing bin.
dustbin.store(objWithMeta);

Also, if we decide links are useful, there's no reason I we can't implement them using this system.

[lordnull]

Generating a property '$metadata' which is an object seems the best option. Unless iterating over the properties of the object we can ignore it, but it's there with useful data. Using an object allows for easy extension without polluting the object to be stored any more than absolutely needed (as you demonstrate with #5).