You might be thinking of Core Data - they REALLY want you to have back pointing
relationships in Core Data…
On Mar 10, 2015, at 12:48 AM, Chuck Hill wrote:
>
>
> On 2015-03-09, 12:03 PM, "OC" wrote:
>
> Hmmm... I have possibly found the culprit.
>
> Some time ago when optimizing, I have rem
On 2015-03-09, 12:03 PM, "OC" wrote:
Hmmm... I have possibly found the culprit.
Some time ago when optimizing, I have removed a number of unused (and big) 1:N
relationships, leaving just the small and fast inverse ones.
(Incidentally... does my memory play tricks on me, or there really used t
Hmmm... I have possibly found the culprit.
Some time ago when optimizing, I have removed a number of unused (and big) 1:N
relationships, leaving just the small and fast inverse ones.
(Incidentally... does my memory play tricks on me, or there really used to be a
time when a relationship without
Chuck,
On 5. 3. 2015, at 18:44, Chuck Hill wrote:
> It might happen if you have a temporary GID. Are you using parent and child
> editing contexts?
Nope, at the moment I am using peers only. (But I intend to switch to nested
ECs in new version for object creator/editor pages, which at the mome
It might happen if you have a temporary GID. Are you using parent and child
editing contexts?
On 2015-03-03, 2:47 PM, "OC" wrote:
Hello there,
in my latest log, there is (thrice) a NPE at
at
er.extensions.eof.ERXDatabaseContextDelegate.batchFetchToOneFault(ERXDatabaseContextDelegate.java:7
Hello there,
in my latest log, there is (thrice) a NPE at
at
er.extensions.eof.ERXDatabaseContextDelegate.batchFetchToOneFault(ERXDatabaseContextDelegate.java:714)
Looks like it's here:
===
private synchronized boolean batchFetchToOneFault(EODatabaseContext
dbc, AutoBatchFaultingEnt
