fastmail / ix Goto Github PK

For any entity types that have virtual properties, those properties should come back in the response to creating new entities. This way a client stays in sync with the data on the server.

In the current implementation, these virtual properties are only filled in on responses to getFoo calls.

DBIx::Class is already fork and thread safe - so I'm not sure why you don't just ->connect a single $schema early on and hang on to it?

Right now, virtual properties can be anything. For example, a virtual property could be "is_recent" that compares the creation time of an entity against now() and returns true if created in the last hour or false otherwise.

The problem here is that apparent data on the objects can change value but not change the 'state' of the class of objects.

Say our current state is 0, and we call setFoos/create. Our state becomes 1, and our object has a is_recent of true.

In 2 hours, is_recent is now false, but state is still 0. Now our client and server are out of sync, and if the client says getFooUpdates sinceState => 1, the server will say nothing has changed.

Is this something we can defend against consumers mistakenly doing, or should we minimize these types of issues through the documentation?

And, while you're at it, a README.md or .pod would help too :-)