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

Multiple Storable Objects #37

Closed
crisward opened this issue Feb 27, 2017 · 4 comments · Fixed by #43
Closed

Multiple Storable Objects #37

crisward opened this issue Feb 27, 2017 · 4 comments · Fixed by #43

Comments

@crisward
Copy link
Contributor

If I set multiple storable objects, the object type seems to get mismatched. This seems to happen when the data gets read back from a file, and it parsed with .from_json.

Let me know if you need more info to recreate.

@neovintage
Copy link
Contributor

@crisward can you post an example? That would help me a ton.

@crisward
Copy link
Contributor Author

Will do. I've worked around this at the moment by creating a session schema object and storing everything in there as per this discussion - #38.

I'll try and add a failing test...

@neovintage
Copy link
Contributor

Alright, I think I figured it out. The specs as they exist today between UserTestSerialization and UserTestDeserialization will result in type mismatches when parsing the json from the storage instance. The reason this happens is that when a union type is deserialized from JSON, crystal will go through all the types within the union until one of them parses correctly. Unless the converter method throws an error, it's likely that you'll get a parse mismatch on deserialization. If you have different classes but they happen to have the same properties, like in cases where you subclass, you're always going to get the incorrect type.

Our options include:

  1. include the actual type when serializing the Storable Object to session storage.
  2. Only allow one storable object across a code base

I'm in favor of the first option. I think that's going to mean we're going to have to create a wrapper object to allow us to encode the type as part of the storable object. I don't think that will require the storage engines to have to change their implementations but I'm not sure at this point.

I think there's a way forward but I'm not sure when I can get some time to fix it.

@crisward
Copy link
Contributor Author

crisward commented Apr 9, 2017

I went with option no.2 in my usage and just have a big 'session' object which I've attached my other objects to, as per this discussion - #38. Sorry I never did get around to giving an example. It was a case of finding a solution and moving on. I intend to write a mysql implementation of session storage once these kind of implementation details are ironed out.

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

Successfully merging a pull request may close this issue.

2 participants