Adrian Sampson

Hi, @Boehemyth—glad you're interested! Yes, the recent work in MediaFile is the first step toward making this work more generally. The next step—which is arguably even more challenging—is to cleanly...

Here are two reasons for adding list-valued fields everywhere: - Attachments (see #111) should be built on flexible attributes. We should allow multiple attachments of the same type, which will...

> The issue is that if we really want to make this work for EVERY field, things are going to get messy very quickly. I actually don't know whether I...

Yes, it would be great to avoid a separate table for every list-valued field! I can only think of two ways around this, both of which have obvious issues: -...

Thanks for all the thoughts on this! We should indeed get moving on list-valued fields. I'm a little confused about your comment about conversion to strings. I am pretty sure...

You make lots of great arguments for why the key/value approach would also be inefficient. Clearly, what we _really_ want here is a document-oriented database and we're working around the...

Yes, there are suspicious performance problems with some of the alternative databases. But if we're going to be comparing with data, it might also make sense to compare against those...

No, it's a little opaque in terms of project status. Maybe it's worth contacting the author?

Very cool; BlitzDB is indeed very promising. One unfortunate wrinkle is that the current backend uses a directory full of individual JSON files, which is somewhat inconvenient compared to a...

That's odd! @dosoe, would you mind taking a look?