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 instance to do this processing?
Chuck 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]
