Chuck,
On 2. 3. 2016, at 19:32, Chuck Hill <[email protected]> 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,
> "[email protected] on behalf of
> ocs.cz" <[email protected] on behalf
> of [email protected]> 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()%1000==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 protected])
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com
>>
>> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
