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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAJdcQk3s9jnXR6VJEyhXSFHPO0qNNBBnRrm7A3Pr%2BukU5Q9DmQ%40mail.gmail.com.
