Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support skipping row serialization of some entities #197

Open
johann2 opened this issue Oct 17, 2021 · 2 comments
Open

Support skipping row serialization of some entities #197

johann2 opened this issue Oct 17, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@johann2
Copy link

johann2 commented Oct 17, 2021

Right now, all the entities in the world get serialized. It's useful to only serialize a subset of them, though. For example, to save on network bandwidth, disk space, or if some entities are generated from some other data source and there's not much point to serialize them.

The most obvious way would be to add a is_serializable(EntityRef)->bool function to SerializeContext trait. Then in the serialize function it should be called for every entity and if it returns false, the whole entity is skipped.

While I understand it's relatively easy to implement outside of the library(I've already done so), I think it's common enough use case that it's worth to consider including it in the library.

@Ralith Ralith added the enhancement New feature or request label Oct 18, 2021
@Ralith
Copy link
Owner

Ralith commented Oct 18, 2021

Given the utterly trivial implementation, I have no objection to providing this. In general, my stance on externally-implementable functionality has softened to including conveniences when they're sufficiently helpful and strongly encapsulated.

@Ralith
Copy link
Owner

Ralith commented Nov 4, 2021

Taking a slightly closer look at this, there's a wrinkle: skipping entities makes it harder to know in advance how many entities will be serialized. We could stop supplying a known length to the relevant serialize_map call and break serializers that depend on it, e.g. bincode, or we could make two passes over the world, which feels pretty ugly.

While neither of those are disasters, the optimal tradeoff will vary from application to application, which weakens the case for providing this behavior out-of-the-box. The serialization code is after all intended to be simple and easy to get good results with and serve as example code for custom solutions, not to address every use case itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants