I use this approach every once in a while.... it's important to
realize that if you perform transactions on these types of entities,
you will likely have stale data in other entities that are based on
the same database data. If you make changes to these EOs, you have to
worry about refreshing the other entities on your own.
On Apr 30, 2008, at 8:01 PM, William Hatch wrote:
> Ah, one more thing I probably should have mentioned earlier: you can
> certainly create entities that are subsets or supersets of existing
> entities. This is in fact how certain types of inheritance are
> modeled using eof. They don't have to be related, but if you'll be
> creating both types, you'll need to be mindful of foreign key
> constraints as well as primary key generation.
>
> Bill
>
>
> On Apr 30, 2008, at 1:46 PM, William Hatch wrote:
>
>> Hi Stefan,
>>
>> There's two (at least) answers here. First, EOF will support db
>> views as Entities, so if you want to transfer the weight of
>> organizing the data onto the db, this is a good solution. Second,
>> it sounds like you're asking about how to limit the amount of eo
>> object creation and faulting happening with the entities related to
>> the primary entity (Task) of the fetch in question. Check your
>> prefetch settings in the model for all the relationships in
>> question. If you're not displaying any of that data, then it
>> shouldn't be a big deal. If you're using keys into a relationship
>> for the qualifier, then solution one may be best. Also, you may
>> want to combine option one with raw rows fetching and craft your
>> own logic to convert from view dictionary to Task EO; this may help
>> realize some significant performance benefits.
>>
>>
>> Bill
>>
>>
>> On Apr 30, 2008, at 11:57 AM, Stefan Andiel wrote:
>>
>>> Dear list,
>>>
>>> in my application there is a page, which shows tasks. So in my
>>> model is also a entity called Task. This entity is associated to
>>> other entities, like CallCenterEmployee, Customer, Incident, etc.
>>> When I declare a fetch onto task, EOF gathering all objects which
>>> are connectet to the object path. Due to the problem that entities
>>> which are associated to Customer are huge I gotg a long response
>>> tine.
>>> But only to show this piece of information, I don't need the deep
>>> objects of these entities.
>>>
>>> Now my question.
>>> I declare a View Statement to my frontbase database. Is it
>>> possible to use the genereated objects as inner class in the task
>>> page. If so the I would ty to load a task by its id, or at the
>>> other hand
>>> is it possible to set a fetch to a limited deepness? AFAIK I can
>>> only the a fetch with deepp search or not, but not with a limit.
>>>
>>> Thanks in advance
>>> Stefan
>>>
>>> --
>>> Dipl.-Inform. Stefan Andiel
>>> Starhealthcare GmbH
>>>
>>> Pierstraße 8, 50997 Köln
>>> Fon: +49 2236 33 66 5-50 Fax: +49 2236 33 66 5-90 http://www.starhealthcare.info
>>> Geschäftsführer: Michael Klennert, Peter Brimmers
>>> Sitz der Gesellschaft: Köln, Amtsgericht Köln, Reg.Nr.: HRB 55306
>>>
>>
>
This archive was generated by hypermail 2.0.0 : Thu May 01 2008 - 12:03:32 EDT