Re: a trick to model a complex derived relationship?
Re: a trick to model a complex derived relationship?
- Subject: Re: a trick to model a complex derived relationship?
- From: OC <email@hidden>
- Date: Sun, 06 Mar 2016 18:33:40 +0100
Chuck,
On 4. 3. 2016, at 5:37, Chuck Hill <email@hidden> 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 right, hopefully.
> Ideally, changing the model is only done before app startup before any requests are processed. You could run a special instance to do this processing?
Alas, not easily: the relationships which I am flattening programmatically are defined through data entered by user at runtime.
If worst comes to the worst, I probably could do something like “all flattened relationships which can be used must be predefined through (say) a Properties item, but it would complicate things noticeably, and if possible, I would rather dodge that.
Thanks a lot!
> On 2016-03-02, 12:18 PM, "OC" <email@hidden> wrote:
>
>> Chuck,
>>
>> On 2. 3. 2016, at 19:32, Chuck Hill <email@hidden> 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 appropriate restricting qualifiers for these conditions might possibly work. Then you could define the flattened relationship in terms of these restricted entities.
>>
>> Thanks a lot! Meantime, I am doing it step-by-step: first, I fetch only PKs; then for the specific PKs it is comparatively easy to construct a qualifier to fetch only the appropriate user PKs -- and in the last step, I fetch the desired attributes for those PKs. Somewhat convoluted, but manageable. Thank you for the advice; I'll check the possibility of qualified entities (of which I completely have forgot!), it might lead to a cleaner and more efficient code.
>>
>> Incidentally, I am using a ReentrantReadWriteLock to keep the access to the model duly serialized, essentially like this (sans error checking, exception harnesses etc. of course):
>>
>> ===
>> rrwlock.readLock().lock()
>>
>> if (need-to-add-flattened-attributes) {
>> rrwlock.readLock().unlock(); rrwlock.writeLock().lock()
>>
>> add-flattened-attributes
>>
>> rrwlock.readLock().lock(); rrwlock.writeLock().unlock()
>> }
>>
>> read-data-using-flattened-attributes
>>
>> rrwlock.readLock().unlock();
>> ===
>>
>> I am sure no other code uses this particular model, ever. Originally it seemed all right and it does work without a glitch so far, but meantime it occurred to me -- is it safe to potentially use _other_ models in the same model group (i.e., about any EOF code throughout the whole application) whilst this one model is changed?
>>
>> If not, is there a way to lock out „any kind of usage of a model group, anywhere“ while I am changing the model?
>>
>> Thanks a very big lot again,
>> OC
>>
>>
>>> On 2016-03-01, 11:25 AM, "webobjects-dev-bounces+chill=email@hidden on behalf of ocs.cz" <webobjects-dev-bounces+chill=email@hidden on behalf of email@hidden> wrote:
>>>
>>>> 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 fetch the data as raw rows into another, essentially unrelated application.
>>>>
>>>> For example, in my application Auction.woa, there is a DBAuction entity; in its code, there is (essentially) this derived relationship:
>>>>
>>>> ===
>>>> DBUser auctionOwner() {
>>>> for (DBUserAccess ua in userAccess()) // userAccess is a 1:N relationship from this to DBUserAccess
>>>> if (ua.accessAllowed()) { // accessAllowed is a boolean attribute of DBUserAccess
>>>> DBUser user=ua.user() // user is an N:1 relationship from DBUserAccess to DBUser
>>>> if (user.userType()00==USER_TYPE_OWNER) // userType is an integer attribute of DBUser; USER_TYPE_OWNER a constant
>>>> return user
>>>> }
>>>> return null
>>>> }
>>>> ===
>>>>
>>>> Now, the problem is that I would need to fetch data _as raw rows_ through this relationship into _another application_, say, AuctionImporter.woa, where none of the entities exist. (Even if I copied the entities there, it would not help with fetching raw rows.)
>>>>
>>>> For modelled attributes and relationships I have solved the problem by creating a copy of the Auction model in my AuctionImporter.woa application, having turned all the model classes to EOGenericRecords. That allows me to fetch raw rows based on all modelled attributes (and flattened attributes through modelled :1 relationships) all right: done, tested, works like a charm.
>>>>
>>>> Now, though, I bumped into a need to fetch raw rows based on these complex “derived” relationships; e.g., I would need to be able to do in AuctionImporter.woa something like
>>>>
>>>> ===
>>>> def fs=new EOFetchSpecification("DBAuction",null,null) // DBAuction entity from the copy of the original model
>>>> fs.fetchesRawRows=YES
>>>> fs.rawRowKeyPaths=['auctionOwner_login', ... normal modelled (potentially flattened) attribs, no problem with them ...]
>>>> def result=new ERXEC().objectsWithFetchSpecification(fs)
>>>> ===
>>>>
>>>> Is there a trick to define at the model level a “derived relationship“ auctionOwner, simulating somehow the behaviour described above, through which I then would be able to flatten the desired attribute (with a definition "auctionOwner.login")?
>>>>
>>>> If this is not possible, it seems to me I would have to generate the complete fetch SQL myself, essentially without any help of EOF, and then fetch using EOUtilities.rawRowsForSQL. Ick. That can get pretty complex pretty quickly[*], and thus I would rather like to dodge it, if possible. Can you see any easier way to do this?
>>>>
>>>> Thanks for any advice,
>>>> OC
>>>>
>>>> [*] Originally, I have considered it for attributes flattened through modelled relationships, too. It quickly proved _much_ easier to add appropriate flattened attributes to the model (syncing appropriately to make sure model never gets changed by one thread and accessed by another at the same time), and let EOF to generate the SQL for me :)
>>>>
>>>>
>>>> _______________________________________________
>>>> 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