• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: qualified to-many relationships?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qualified to-many relationships?


  • Subject: Re: qualified to-many relationships?
  • From: Chuck Hill <email@hidden>
  • Date: Mon, 11 Jul 2016 15:51:08 +0000
  • Thread-topic: qualified to-many relationships?

Yes, it makes it behave as if each was in its own instance.    Are you dependent on running in a single instance?   

 

You need to create a new EOObjectStoreCoordinator for each session/group and pass it to the EOEditingContext constructor.  As you want to mutate the model, you will also need to create a new EOModelGroup and clone the models into it.  I forget at the momemt where this new group gets setModelGroup() in.  You also need to ensure that none of your code or called Wonder code etc uses EOModelGroup.defaultGroup()

 

 

Chuck

 

From: OC <email@hidden>
Date: Monday, July 11, 2016 at 5:25 AM
To: Chuck Hill <email@hidden>
Cc: WebObjects-Dev Mailing List <email@hidden>
Subject: Re: qualified to-many relationships?

 

P.S.

 

Well I _am_ sort of at the slow side today.

 

I guess this might bring nasty problems with EOs *not* synchronized, right? The net effect would be essentially the same as if each session run in its own instance, or am I wrong?

 

Thanks again,

OC

 

On 11. 7. 2016, at 13:12, OC <email@hidden> wrote:

 

I see.

Can you please nudge how would one do the „EOF stack per session“ (or per a selected number of sessions, but not all of them) magic? I guess I should know, but my old dumb brains does not seem to co-operate much at the moment :)

Thanks a lot,

OC

On 11. 7. 2016, at 6:47, Chuck Hill <email@hidden> wrote:

This is why you want an EOF stack per session.  This the only way to have very different configurations per session.   Without that, I don’t think that ERXEnterpriseObjectArrayCache is going to help you much.  You need to configure an isolated EOF stack per session to show that session just the data that is appropriate to it.

Chuck

From: OC <email@hidden>

Date: Sunday, July 10, 2016 at 5:23 AM

To: Chuck Hill <email@hidden>

Cc: WebObjects-Dev Mailing List <email@hidden>

Subject: Re: qualified to-many relationships?

Chuck,

On 9. 7. 2016, at 11:54, OC <email@hidden> wrote:

Meantime I have realised one thing: the "qualifiedRecords" are current-user (i.e., session) dependent in such a way that for a given session which needs to qualify them, there will *never* be need to fetch the other records. Completely all fetches, which originate in that session, should be filtered. The demand is “a specific user should never see some records; from his point of view, the application should look like they do not exist.“

Might perhaps EOF or Wonder allow some trick therefore not to implement "qualifiedRecords", but, instead, for all database operation which belong to a specific session, to _always_ filter _all_ fetches of "records" (or even better, _completely all_ fetches of the T_RECORD table, whichever way they did origin!) by a given qualifier?

Well, as you probably have seen at the first look, this was one of my (frequent) not-so-bright ideas. It seems e.g., the dbcontext delegate can do it all right and it works excellently: whichever thing gets fetched from given entity on behalf of a given user gets perfectly filtered.

The only limitation is that other sessions would have to have different (or none at all) qualifiers

You know the result: if another user wants the data later, they, of course, are not fetched in his behalf; instead, they come from shared caches, already (improperly) filtered for the original user, whose request did fetch. Oops.

I suppose, even if I managed to

clone the model into a new, user specific EOModelGroup

and add the restricting qualifier to the DBRecord entity in there?

it would lead to the same problem: presumably the entity restricting qualifier would be used fetch-time; and the next time another user wants the data, he would get cached ones, which means, for him, wrong list.

Thus I am afraid indeed

none of this is (reasonably) possible

and truly

I shall need to fall back to the originally considered way of:

To achieve this you need to:

1.       Write the access method like yo have below, but cache the result for performance.

2.       Write the mutator methods (if you need them) to work on the original EOF relationship

3.       Modify the mutator methods of the original relationship to either invalidate or update this cache (update is faster but harder to write)

4.       Intercept certain EOF operations/notifications so that the cache can be updated or invalidated when EOF changes the underlying snapshots

I can dig the details for (4) out for you if you want to pursue this.

and I would be then pretty grateful for that.

If you can spare a moment, let me please know.

Might perhaps ERXEnterpriseObjectArrayCache help here? From its documentation it sort of seems it might perhaps be listening to those notifications to keep up to date automagically, but I have never used the thing and am not sure by far I understand the documentation...

Thanks a big lot!

All the best,

OC

From: <webobjects-dev-bounces+chill=email@hidden> on behalf of OC <email@hidden>

Date: Friday, July 8, 2016 at 1:11 AM

To: WebObjects-Dev Mailing List <email@hidden>

Subject: qualified to-many relationships?

Hi there,

is there a way to define and use a to-many relationship, derived from a modelled one, by limiting the results by a qualifier?

I have got an entity, say, "DBTable", whose to-many relationship "records" returns a set of eos of entity "DBRecord". That works all right.

Now, I need to implement a "qualifiedRecords" relationship, which would work this way:

===

class DBTable ... {

  NSArray qualifiedRecords {

    EOQualifier qq=ERXSession.session().recordQualifier; // the qualifier depends on current user and other conditions of the current session

    return EOQualifier.filteredArrayWithQualifier(this.records(),qq);

  }

}

===

With small objects, I would use precisely the code above. Alas, my DBTables contain _lots_ of DBRecords, and thus the above implementation would get terribly slow by fetching all of them and then re-filtering them each time the relationship is accessed.

What I need here is same behaviour functionality-wise, but at a lower level, sort of like EODatabaseDataSource's auxiliaryQualifier, but somehow bound to the particular relationship, so that

(a) it is not needed to fetch all records -- the "qualifiedRecords" relationship would, when fired, automatically fetch only the qualified ones

(b) records are fetched once and then cached, just like it is with normal relationships

(c) I can use things like

ERXEOControlUtilities.objectCountForToManyRelationship(sometable,"qualifiedRecords")

etc. seamlessly, and they work as expected.

Is there a way to do this at all? Perhaps I am just blind, but I cannot find any decent solution :/

Thanks and all the best,

OC

_______________________________________________

Do not post admin requests to the list. They will be ignored.

Webobjects-dev mailing list      (email@hidden)

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

_______________________________________________

Do not post admin requests to the list. They will be ignored.

Webobjects-dev mailing list      (email@hidden)

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

_______________________________________________

Do not post admin requests to the list. They will be ignored.

Webobjects-dev mailing list      (email@hidden)

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

 

 

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >qualified to-many relationships? (From: OC <email@hidden>)
 >Re: qualified to-many relationships? (From: Chuck Hill <email@hidden>)
 >Re: qualified to-many relationships? (From: OC <email@hidden>)
 >Re: qualified to-many relationships? (From: OC <email@hidden>)
 >Re: qualified to-many relationships? (From: Chuck Hill <email@hidden>)
 >Re: qualified to-many relationships? (From: OC <email@hidden>)
 >Re: qualified to-many relationships? (From: OC <email@hidden>)

  • Prev by Date: Re: Horizontal inheritance to splitting big database tables to speed up?
  • Next by Date: Re: Intercepting a failed action method invocation
  • Previous by thread: Re: qualified to-many relationships?
  • Next by thread: Re: qualified to-many relationships?
  • Index(es):
    • Date
    • Thread