Joins are just done by following relationships, but as with fetching EOs you need to do one fetch per entity (or entity hierarchy). Otherwise, I think you are correct that you need to use SQL. Or you could fetch them as EOs with pre-fetching and then extract the dictionary from the snapshot of each EO.
You don’t want to me altering the model in a multi-threaded app while those threads are running. Havoc would result. Chuck On 2016-02-22, 11:30 AM, "OC" <o...@ocs.cz> wrote: >Chuck, > >On 22. 2. 2016, at 19:18, Chuck Hill <ch...@gevityinc.com> wrote: > >> It sounds to me like sharing the model would be less effort. > >Thanks! > >> Rather than use rawRowsForSQL you can just make regular fetch specs and tell >> them to fetch raw rows. You might get more data back than you need, but all >> the join and name translation etc will be handled for you. > >This looks like a trick I don't know yet. How do I ensure a join using a >regular fetchspec? > >Assume a pretty trivial case, entity "Person" having attribute "name" and >relationship "department", which leads to entity "Department" with attribute >"name". > >I need to get an array of dictionaries, which will represent all persons and >their departmens; the keys will be "name" and "department.name", the values >self-evident. > >Short of fetching raw rows twice and post-processing (which is what I want to >dodge, leaving the heavy stuff on the db server), how do I get this kind of >dictionaries, if not by creating the appropriate SQL myself? > >Note that there's no flattened attribute in the model. Hmmm.... well I >probably might add one programmatically on-the-fly just before the fetch, >never tried that... wouldn't that bring havoc though if more threads fetched >concurrently and each extended the model its own way? > >Thanks a very big lot, >OC > > >> On 2016-02-21, 6:40 AM, >> "webobjects-dev-bounces+chill=gevityinc....@lists.apple.com on behalf of >> ocs.cz" <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com on >> behalf of o...@ocs.cz> wrote: >> >>> Hello there, >>> >>> my web app should occassionally import from an external DB (a database >>> created and maintained by another WO-based application). Just import, and >>> only low-level dictionaries at that, never full-fledged EO-objects. >>> Probably though, the imported tables would be rather big, it would be >>> needed to join them (i.e., import also attributes accessible through a >>> relationship), etc. >>> >>> Having so far no experience with accessing another DB, I wonder. >>> >>> Would I gain anything of importance by sharing the model and using EOF for >>> the import (in which case, due to them joins, I am afraid I would have to >>> go as low as to EOUtilities.rawRowsForSQL anyway), or would you rather, in >>> this special case, skip EOF altogether and go DIY at the JDBC level? (The >>> latter approach would lead to reading in the other app's model anyway, but >>> without using the EOF stack over it, just to manually translate entity and >>> property names to tables/columns, nothing more.) >>> >>> Thanks, >>> OC >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com >>> >>> This email sent to ch...@gevityinc.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
