We're working on multiple applications with dynamic schemas: schemas where customers need to be able to add or delete fields to meet their particular requirements. This sort of thing impacts both the database layer and the wire schema. I can think of an implementation that doesn't suck (see below), I'm wondering what the best way would be to handle this sort of thing in capnproto.
The doesn't suck approach: In this application we can restrict in advance what the valid types are for these new columns, which would allow us to handle the dynamic fields as a list struct/union values, each carrying its field name as a string or something similar. It's not an especially elegant way of describing the protocol, but it covers the use cases. It isn't *necessary* that the bits on the wire be "pretty", it's reasonably easy to decode into JavaScript objects on the client, and it doesn't seem like a huge lift on the server to validate that all expected extension fields are present and have values of the expected type. Is there a better way to think about this? Jonathan -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAJdcQk3s9jnXR6VJEyhXSFHPO0qNNBBnRrm7A3Pr%2BukU5Q9DmQ%40mail.gmail.com.
