Brainstorm: cw-storage-plus support when key can be derived from stored object

[ethanfrey]

Based on a PR comment: #109 (comment)

If we think in typical DBs, the primary key is part of the object being saved. We don't think of these separately. If we define objects like this, then we don't have to pass in the key in save, but can derive it from the saved object.

Thinking more, it is just that one method - load, may_load, update and remove all require the full key in any case.

@maurolacy if you still like this idea, can you develop it more. Once I started to flesh it out, I think it doesn't really have much use.

[maurolacy]

I don't think this is a good idea in the end, because the pk must be unique. Relying on the first data item either wouldn't guarantee uniqueness, or would force you to introduce an id or pk field at the beginning of it. Which will not only take space as data, but will also be equally or even more difficult to deal with, than specifying the pk directly.

I think the only way this could be an improvement, is if we implement automatic numerical ids, like the AUTO_INCREMENT feature of numerical fields, in relational databases. That would probably make sense, but it will require a good level of redesign. Perhaps even a different data structure.

So, I am of the opinion of closing this without changes.

[ethanfrey]

Sounds good to me.
This could make a nice API, but would be a much different design than we have now.
Someone could build a storage-plus alternative if they wished to really make something like SQL indexes