Oh you're not just a cross-model relationship, you're a cross
DATABASE relationship. Yes, this does have problems in EOF. I
believe that it works if all you do is say company.employees() and
company is one db, and employees is in another, but I think if you
start building up qualifiers that traverse those relationships
further than just the cross-database foreign key, it has problems.
The fundamental issue is that EOF is not able to evaluate a qualifier
in two different adaptors, meaning, you can't have a qualifier that
is half SQL and half in-memory, or half SQL in one DB and half in
another. It makes sense when you think of the generalization of this
problem and how insane it becomes (start thinking nested ands and ors
with mixed-and-matched qualifiers crossing adaptors). I ran into
this same thing with my JavaIMAPAdaptor where I wanted to be able to
partially evaluate a query against messages in IMAP and partially in
memory and it's REALLY hard to do.
ms
On Jul 27, 2007, at 2:39 PM, Thomas wrote:
> Just a display bug! (...sound of wild histrionics...)
>
> Being new to Eclipse, I spent nearly a day trying to track down a
> still unresolved database fetch problem. Most of that time was
> spent trying to fix models that were not broken, but appeared to be
> be broken in Entity Modeler.
>
> I very much look forward to when I can safely use 3.3.
>
> By the way, here is the cross-model relationship fetch problem. The
> first attempt, which I have used before, results in SQL that says
> the related entity is in the same database, which of course fails:
>
> EOUtilities.objectsWithQualifierFormat(session
> ().defaultEditingContext(), "CMSNotice", "toNoticeType.title = ..,
> new NSArray("Page Template"));
>
> But if I do it with in-memory filtering it works:
>
> NSArray notices = EOUtilities.objectsForEntityNamed(session
> ().defaultEditingContext(), "CMSNotice");
> return EOQualifier.filteredArrayWithQualifier(array,
> EOQualifier.qualifierWithQualifierFormat("toNoticeType.title = %
>.., new NSArray( "Page Template")));
>
> I still don't understand why the former doesn't work, but I have
> found a workaround and still have a great deal to learn about
> Eclipse before I get productive again, so I will move on...
>
> Thomas
>
> On 27/07/2007, at 22:25, Mike Schrag wrote:
>
>>> This would be the difference between:
>>>
>>> _modelComboViewer.setSelection(new StructuredSelection
>>> (_relationship.getEntity().getModel()));
>>>
>>> and
>>>
>>> _modelComboViewer.setSelection(new StructuredSelection
>>> (_relationship.getDestination().getModel()));
>>>
>>> This would seem to be just a display bug -- Is it actually
>>> breaking something in your model? (and fixed in the 3.3 version)
>>>
>>> ms
>>>
>>> On Jul 27, 2007, at 3:01 AM, Thomas wrote:
>>>
>>>> Yes, the plist file is correct. It only shows the entity name,
>>>> not the model where the entity comes from.
>>>>
>>>> But I have reproduced this problem in a new test project with
>>>> two very simple models with just enough info to make a cross-
>>>> model relationship. Setting up the relationship works, but when
>>>> you inspect something else, eg an attribute, and then inspect
>>>> the relationship, the Model is shown as the local model instead
>>>> of the foreign model, and the Destination is blank. This despite
>>>> the plist file being correct. This happens in all my models in
>>>> all my projects.
>>>>
>>>> I have tried this on two different Eclipse installations, one
>>>> the latest and one older, and I get the same result.
>>>>
>>>> If anybody can reproduce this, I will file a bug. If not, I will
>>>> quietly commit hari-kiri.
>>>>
>
This archive was generated by hypermail 2.0.0 : Fri Jul 27 2007 - 14:47:42 EDT