Hello there,
in my code, there is a number of “derived relationships”, defined by Java code
at the EO class level. It works well for years, but now (as part of the “import
another application's database” task I am working on) I would need to move the
behaviour to the model level, so that I can
There is no way to filter/qualify relationships in the model. You could model
and flatten Auction ->> Users but that is going to include users for whom
access is not allowed and non-owner users.
Defining additional entities with the appropriate restricting qualifiers for
these conditions might
Chuck,
On 2. 3. 2016, at 19:32, Chuck Hill wrote:
> There is no way to filter/qualify relationships in the model. You could
> model and flatten Auction ->> Users but that is going to include users for
> whom access is not allowed and non-owner users.
>
> Defining additional entities with the
Chuck,
On 2. 3. 2016, at 21:18, OC wrote:
>> Defining additional entities with the appropriate restricting qualifiers for
>> these conditions might possibly work. Then you could define the flattened
>> relationship in terms of these restricted entities.
>
> ... Thank you for the advice; I'll
Hi,
On 2016-03-02, 4:30 PM, "OC" wrote:
>Chuck,
>
>On 2. 3. 2016, at 21:18, OC wrote:
>
>>> Defining additional entities with the appropriate restricting qualifiers
>>> for these conditions might possibly work. Then you could define the
>>> flattened relationship in terms of these restrict
Does the model you are changing have any relationships to other models in the
model group? If not, it should be safe. I can’t think of how it would affect
other models. Ideally, changing the model is only done before app startup
before any requests are processed. You could run a special inst
Chuck,
On 4. 3. 2016, at 5:37, Chuck Hill wrote:
> Does the model you are changing have any relationships to other models in the
> model group? If not, it should be safe. I can’t think of how it would
> affect other models.
Great! The models are completely independent, so it should be all r
Chuck,
On 4. 3. 2016, at 5:26, Chuck Hill wrote:
Defining additional entities with the appropriate restricting qualifiers
for these conditions might possibly work. Then you could define the
flattened relationship in terms of these restricted entities.
>>>
>>> ... Thank you for
Chuck,
short version: with key (not keypath) restrictingQualifier it, alas, does not
work either.
Thanks again a big lot for all the help!
OC
Long version if anybody interested:
(a) given there are two entities, Source and Destination, and a relationship
Source.rel ->> Destination
(b) and we
I may be at bit late to the discussion
Isn't what Chuck described basically a sinlge table inheritance?
You could create SUB-Types based on you User and create separate relationships
to each sub-type (NOT to the generic super type!). This should work
transparently then.
Model something lik
10 matches
Mail list logo
