HOWTO? Lazily Loading HUGE References [message #1707982] |
Fri, 11 September 2015 08:11 |
Bernhard Anzeletti Messages: 17 Registered: July 2011 Location: Austria |
Junior Member |
|
|
Hi all,
we're aiming at a Client/Server application based on EMF. In this szenario, we would like to view "Contracts" that have a HUGE number of "ContractItems". Fortunatly, in most cases users only want to see "Contract" and don't care about "ContractItems".
In order to reduce system load we decided to lazily load "ContractItems". For this we saw two sollutions:
1) On the server, instantiate Contract and all ContractItems. Put the contract in one resource and the items in the other resource. Serialize the ContractResource and return it to the client.. The client recieves a list with proxies. When resolving the first proxy it loads the resource with all ContractItems into its local ResourceSet. Further proxy resolution uses this resources and does not need server interaction anymore.
2) Make an "intermediate node" in the EMF model that "contains" the ContractItems. On the initial request for the "Contract" data, build this intermediate node, link it to the "Contract" node and put both into seperate resources. Seralilize the ContractResource and return it to the client. The client receives a "Contract" node with a proxy to the "intermediate" Node. When resolving this proxy, the server fills the intermediate node with all ContractItems and returns it to the client.
Solution 1) requires data access for each ContractItem even on the initial request, even when only Contract information is required; this is overhead.
Solution 2) introduces an "intermediate node" just for Client/Server (=ProxyResolving) purpose which should not be part of a Domain Model.
[Solution 2 can be amended by "hiding" the intermediate node using a derived relation on the Contract node into the ContractItems that gets the intermediate node's relation, thereby resolving the intermediate node's proxy. Still, the ecore model has to provide the intermediate node]
The Question
Is there a more satisfying solution?
(It would probably require references to have a URI. If this were the case, the whole list can be proxied (=1 Proxy) instead of being a List of Proxies (=n proxies).
Kind regards
Bernhard
|
|
|
Re: HOWTO? Lazily Loading HUGE References [message #1707991 is a reply to message #1707982] |
Fri, 11 September 2015 09:33 |
Erdal Karaca Messages: 854 Registered: July 2009 |
Senior Member |
|
|
If you are using the DBStore, you could select only the items that have the type you want.
Bernhard Anzeletti wrote on Fri, 11 September 2015 10:11Hi all,
we're aiming at a Client/Server application based on EMF. In this szenario, we would like to view "Contracts" that have a HUGE number of "ContractItems". Fortunatly, in most cases users only want to see "Contract" and don't care about "ContractItems".
In order to reduce system load we decided to lazily load "ContractItems". For this we saw two sollutions:
1) On the server, instantiate Contract and all ContractItems. Put the contract in one resource and the items in the other resource. Serialize the ContractResource and return it to the client.. The client recieves a list with proxies. When resolving the first proxy it loads the resource with all ContractItems into its local ResourceSet. Further proxy resolution uses this resources and does not need server interaction anymore.
2) Make an "intermediate node" in the EMF model that "contains" the ContractItems. On the initial request for the "Contract" data, build this intermediate node, link it to the "Contract" node and put both into seperate resources. Seralilize the ContractResource and return it to the client. The client receives a "Contract" node with a proxy to the "intermediate" Node. When resolving this proxy, the server fills the intermediate node with all ContractItems and returns it to the client.
Solution 1) requires data access for each ContractItem even on the initial request, even when only Contract information is required; this is overhead.
Solution 2) introduces an "intermediate node" just for Client/Server (=ProxyResolving) purpose which should not be part of a Domain Model.
[Solution 2 can be amended by "hiding" the intermediate node using a derived relation on the Contract node into the ContractItems that gets the intermediate node's relation, thereby resolving the intermediate node's proxy. Still, the ecore model has to provide the intermediate node]
The Question
Is there a more satisfying solution?
(It would probably require references to have a URI. If this were the case, the whole list can be proxied (=1 Proxy) instead of being a List of Proxies (=n proxies).
Kind regards
Bernhard
|
|
|
Re: HOWTO? Lazily Loading HUGE References [message #1708109 is a reply to message #1707982] |
Sun, 13 September 2015 14:08 |
Ed Merks Messages: 33218 Registered: July 2009 |
Senior Member |
|
|
Bernhard,
Have you considered using CDO?
On 11/09/2015 10:11 AM, Bernhard Anzeletti wrote:
> Hi all,
> we're aiming at a Client/Server application based on EMF. In this
> szenario, we would like to view "Contracts" that have a HUGE number of
> "ContractItems". Fortunatly, in most cases users only want to see
> "Contract" and don't care about "ContractItems".
>
> In order to reduce system load we decided to lazily load
> "ContractItems". For this we saw two sollutions:
>
> 1) On the server, instantiate Contract and all ContractItems. Put the
> contract in one resource and the items in the other resource.
> Serialize the ContractResource and return it to the client.. The
> client recieves a list with proxies. When resolving the first proxy it
> loads the resource with all ContractItems into its local ResourceSet.
> Further proxy resolution uses this resources and does not need server
> interaction anymore.
>
> 2) Make an "intermediate node" in the EMF model that "contains" the
> ContractItems. On the initial request for the "Contract" data, build
> this intermediate node, link it to the "Contract" node and put both
> into seperate resources. Seralilize the ContractResource and return it
> to the client. The client receives a "Contract" node with a proxy to
> the "intermediate" Node. When resolving this proxy, the server fills
> the intermediate node with all ContractItems and returns it to the
> client.
>
> Solution 1) requires data access for each ContractItem even on the
> initial request, even when only Contract information is required; this
> is overhead.
>
> Solution 2) introduces an "intermediate node" just for Client/Server
> (=ProxyResolving) purpose which should not be part of a Domain Model.
> [Solution 2 can be amended by "hiding" the intermediate node using a
> derived relation on the Contract node into the ContractItems that gets
> the intermediate node's relation, thereby resolving the intermediate
> node's proxy. Still, the ecore model has to provide the intermediate
> node]
>
> The Question
>
> Is there a more satisfying solution?
> (It would probably require references to have a URI. If this were the
> case, the whole list can be proxied (=1 Proxy) instead of being a List
> of Proxies (=n proxies).
>
> Kind regards
> Bernhard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03458 seconds