If you’re building a multi-tenant system, then this is not how you do it:
> One customer wants :org/postcode to be integer (i.e. US) and another wants it > to be string (i.e. UK) In a multi-tenant system, you have very few “global truths” and for _anything_ that an end-user may touch, it is not a “global truth” by definition. Therefore you _must_ partition per-user specs either by process (entirely) or via their user ID (or similar) so that they absolutely cannot clash. Also, remember that all of the clojure.core specs _are_ global truths – so they can’t have a different meaning for each user and, more importantly, your system must not allow an end user spec to be created that overwrites a clojure.core spec (and that’s _your_ responsibility when designing a multi-tenant system). It is the responsibility of the multi-tenant system to manage loading and unloading of per-user specs, not just “leave it up to the JVM”. To be honest, if you want per-user isolation on a per-ETL-job basis, your best bet may be to spin each job off in its own JVM container anyway since different jobs could require radically different JVM configurations and resources. That also ensures you can’t have any in-memory data conflicts. This is no different from multi-tenant databases: you either completely partition your per-user data (separate databases/schemas) or you ensure that the user ID is part and parcel of every single key reference into the data store. (for reference, we have a multi-tenant system that runs around 100 different websites with millions of unique user accounts, so keeping per-user data isolated while allowing for certain global shared resources goes with the territory) Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood On 6/12/17, 4:47 PM, "Steve Buikhuizen" <clojure@googlegroups.com on behalf of steve.buikhui...@gmail.com> wrote: I can think of a use-case in support of Mark's position. If you are building a hosted ETL web service (like Mulesoft) and you want users to be able to use spec to validate records flowing through it. One customer wants :org/postcode to be integer (i.e. US) and another wants it to be string (i.e. UK) With a global registry this is not possible. It's possible to spec this but then you need to predict all the data shapes supported i.e. not an open validation system You can prefix the key with an org id e.g. :<id>.org/postcode but if you are hosting a lot of orgs the registry will become large. Removal could help manage space but it would require some kind of registry garbage collection i.e. incidental complexity. Any thoughts on how best to do this with spec? Could a multi-spec help here? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
