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
