site_archiver@lists.apple.com Delivered-To: webobjects-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gevityinc.onmicrosoft.com; s=selector1-gevityinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BDDrqt8BNZygx1m72s440u2MlX/x41MYYeg9FfUQEJ0=; b=hC5Qq0RUlstvlUMipk95ogI0zu1VHl5U6PRZsxKwSMiK6kVSL8I66eXciyCaMDjSEVUO6zW8DXHGuvUNgPmQRZLtjzNILPmpQ2jGdMAna8/eHQAj8WD4S9r5ixoRWItz8B8n5iUgGZR2DDPALvjBFQOsQRw6V4c78AoR/EM3Wvc= Spamdiagnosticmetadata: NSPM Spamdiagnosticoutput: 1:99 Thread-index: AQHUP6z39vUwYN4dv0+f4K4hPBtGeKTWguUA Thread-topic: Flattened one-side M:N fails wildly with SharedEC I am not sure that I am following this correctly. The rule is that no Shared EO should have a relationship to anything that is not also a Shared EO. That includes the tables not materialized into an EO. Chuck From: Webobjects-dev <webobjects-dev-bounces+chill=gevityinc.com@lists.apple.com> on behalf of "ocs@ocs" <ocs@ocs.cz> Date: Wednesday, August 29, 2018 at 8:28 AM To: WebObjects-Dev Mailing List <webobjects-dev@lists.apple.com> Subject: Flattened one-side M:N fails wildly with SharedEC Hi there, just have bumped into another weird (at least to me) behaviour. In my model, there used to be a very standard M:N relationship, which exploits an “invisible” intermediate table, flattened “direct” relationships ad both sides. One of the sides lately went to the sharedEC; thus I made sure to delete this side's flattened relationship. The other side and the intermediate table both stay outside of the sharedEC, so I thought that is all right. It failed miserably with “The shared context recently initialized the object <non-shared-one> which is already registered in this context yadda yadda”, i.e., EOF for some godforsaken reason kept loading the non-shared object (the one whose relationship remained intanct) into SEC along with the shared one (whose relationship were removed all right, no traces remained; I have checked about zillion times). Out of desperation, I have just tried to remov the flattened relationship from the non-shared side, exposing instead the intermediate table, and replacing the flattened relationship by something like === List availablePrototypes { // this is how the original flattened rel has been named def mn=this.db_Prototype_DataBlock // 1:N relationship to the intermediate table, exposed mn.collect { it.valueForKey('prototype') // N:1 relationship from the inmdt table to the shared object } } === and it seems to work all right :-O So, it looks like the culprit was the existence of the flattened rel with definiton “db_Prototype_DataBlock.prototype” at the non-shared side. Is that the intended behaviour? Seems pretty weird to me, but as always, I might be overlooking something of importance. Or should that work even with the flattened relationship, and the problems mean I must have done something wrong elsewhere? Thanks and all the best, OC _______________________________________________ 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/site_archiver%40lists... This email sent to site_archiver@lists.apple.com