Chuck, On 4. 3. 2016, at 5:37, Chuck Hill <[email protected]> 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 protected]> wrote: > >> 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]
