FWIW… I think Chuck offers a clean, direct, and robust way of thinking about this as opposed to working within a default EOF environment to filter records or partition data.
I have a configuration that uses default EOModelGroup for application wide data (users, client configs, etc…) and a separate ModelGroup for the partitioned data. This is based on a Multi-Tennant proof-of-concept by Henrique Prange. For any objects in the default model group that need to reference objects in the isolated OSC, I don’t use modeled relationships, but cover methods with the same naming convention can make the api feel like standard EOF while explicitly managing the fetches under the covers. (I’m conflicted about the wisdom of this though, because I want developers to know that the objects need to be treated in an isolated manner and covering the relationship methods can mask that requirement) Check out https://github.com/hprange/multi-tenant-prototype for the proof-of-concept project. If you look at the Application class, you’ll see newEditingContextForTenant that will give you the editingContext you need. I moved the multi-tenant stuff to a framework principal class since my EO stuff is in it’s own framework and that makes it pretty easy to handle this. I’m grateful to Henrique for this example because it cleaned up some bits that I had been brute-forcing and the (relative) simplicity of this approach reduced memory usage and gives me fewer opportunities to make mistakes that can leak data. Larry On 11 Jul 2016, at 0:38, Chuck Hill wrote: > Hi OC, > > I really, really think that you need to either have a new OSC and > EOModelGroup and EOModels per session or, maybe, per client if clients have > multiple users that login and see the same data. With what you are > describing below, the shared EOF stack and shared snapshots is of zero > benefit. For the very minor cost of a few extra objects, you can have a > fully customized EOF environment for each user. > > Chuck Larry Mills-Gahl elemgee at gmail dot com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
