Re: import from an external DB
Re: import from an external DB
- Subject: Re: import from an external DB
- From: Chuck Hill <email@hidden>
- Date: Mon, 22 Feb 2016 19:45:42 +0000
- Thread-topic: import from an external DB
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" <email@hidden> wrote:
>Chuck,
>
>On 22. 2. 2016, at 19:18, Chuck Hill <email@hidden> 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=email@hidden on behalf of ocs.cz" <webobjects-dev-bounces+chill=email@hidden on behalf of email@hidden> 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 (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden