Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO/SWT.Virtual] Virtual tables and CDOPrefetch
[CDO/SWT.Virtual] Virtual tables and CDOPrefetch [message #986444] Tue, 20 November 2012 12:53 Go to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
Hi,

I would like to ask if somehow it would be possible for a Viewer supporting SWT.Virtual
to invoke CDOPrefetch on an object which would correspond to the number of visual rows when scrolling. So now I can do this:

table.addListener(SWT.SetData, new Listener() {
public void handleEvent(Event event) {
TableItem item = (TableItem) event.item;
int index = table.indexOf(item);
int start = index / PAGE_SIZE * PAGE_SIZE;
int end = Math.min(start + PAGE_SIZE, table.getItemCount());
System.out.println("SWT.SetData i=" + index + ", s=" + start
+ ", e=" + end);
}
});

So when this is on, the listener will print for which rows SWT.Virtual will "fetch" the underlying data ,provided with setInput(List<> ...). Now I have two questions:

1) Wouldn't it be cool, if CDOPrefetch could be called on the root object, to get the next PAGE_SIZE? Is this even possible with CDO? I can set a policy for the a view, or call prefetch with a depth, but fetching a chunk for a specific feature? something like this: object.cdoPrefetch(EStructuralFeature feature, int chunkSize), for CDOResource perhaps the api could be cdoResource.cdoPrefetch(int) which would be applied on eContents().

2) In combination with databinding, would this work? I mean, right now it seems the objects would be fetched to set eAdapters on the targets when for example setting this: EMFObservables.observeMaps(
listContentProvider.getKnownElements()
Could the adapters be attached "lazily" as well?

Has anyone looked into this? What would it take to make this happen?

Thanks Christophe Bouhier








Re: [CDO/SWT.Virtual] Virtual tables and CDOPrefetch [message #986536 is a reply to message #986444] Tue, 20 November 2012 20:01 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
Update:

I went to explore this myself, Tom's blog covers the topic, generic for Data binding and specific for using a grid. http://tomsondev.bestsolution.at/2011/10/07/jface-viewer-and-eclipse-databinding-with-10-000-objects/

The solution I have now is to use an ILazyContentProvider, which would update the viewer, with the appropriate CDO Object, like this:

tblViewer.setContentProvider(new ILazyContentProvider() {

			private TableViewer viewer;
			private EList<?> content;

			public void dispose() {

			}

			public void inputChanged(Viewer viewer, Object oldInput,
					Object newInput) {
				this.viewer = (TableViewer) viewer;
				this.content = (EList<?>) newInput;

			}

			public void updateElement(int index) {
				viewer.replace(content.get(index), index);
			}
		});

tblViewer.setInput(toleranceResource.getContents());


This doesn't bind the input collection, but it's amazingly fast. The really nice thing is that when scrolling the viewer, you can actually see the roundtrips to the CDO server, so very dynamic. When it comes to sorting or filtering, that's no longer possible with this solution, but it would be possible to compose a CDO Query from user input.

Also in this case, prefetching is really not needed. One thing remains, which is registering notification listeners, so we can be updated in case an object changes. (The whole point of binding). As we know which objects are being requested for updates by the ILazyContentProvider, it might actually be possible to register a notification listener dynamically...


Cheers Christophe










Re: [CDO/SWT.Virtual] Virtual tables and CDOPrefetch [message #986569 is a reply to message #986536] Wed, 21 November 2012 00:15 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Hi Christophe,

This is actually a quite interesting topic and I'd appreciate to hear about your further findings. Maybe we can derive
something generic and ship it with CDO.

I think that CDOObject.cdoPrefetch() is not very helpful in this context. But partial collection loading (PCL), i.e. the
ability to not load all list element IDs at once could have a positive impact. Please have a look at
CDOSession.Options.setCollectionLoadingPolicy(). You can also combine that with a revision prefetching policy:
CDOView.Options.setRevisionPrefetchingPolicy(). Both mechansims are explained in
http://wiki.eclipse.org/CDO/Tweaking_Performance .

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Am 20.11.2012 21:01, schrieb Christophe Bouhier:
> Update:
> I went to explore this myself, Tom's blog covers the topic, generic for Data binding and specific for using a grid.
> http://tomsondev.bestsolution.at/2011/10/07/jface-viewer-and-eclipse-databinding-with-10-000-objects/
>
> The solution I have now is to use an ILazyContentProvider, which would update the viewer, with the appropriate CDO
> Object, like this:
> tblViewer.setContentProvider(new ILazyContentProvider() {
>
> private TableViewer viewer;
> private EList<?> content;
>
> public void dispose() {
>
> }
>
> public void inputChanged(Viewer viewer, Object oldInput,
> Object newInput) {
> this.viewer = (TableViewer) viewer;
> this.content = (EList<?>) newInput;
>
> }
>
> public void updateElement(int index) {
> viewer.replace(content.get(index), index);
> }
> });
>
> tblViewer.setInput(toleranceResource.getContents());
>
>
> This doesn't bind the input collection, but it's amazingly fast. The really nice thing is that when scrolling the
> viewer, you can actually see the roundtrips to the CDO server, so very dynamic. When it comes to sorting or filtering,
> that's no longer possible with this solution, but it would be possible to compose a CDO Query from user input.
> Also in this case, prefetching is really not needed. One thing remains, which is registering notification listeners,
> so we can be updated in case an object changes. (The whole point of binding). As we know which objects are being
> requested for updates by the ILazyContentProvider, it might actually be possible to register a notification listener
> dynamically...
>
> Cheers Christophe
>
>
>
>
>
>
>
>
>
>
>
Re: [CDO/SWT.Virtual] Virtual tables and CDOPrefetch [message #986624 is a reply to message #986569] Wed, 21 November 2012 09:00 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
Hi Eike,

Lazy loading is really cool, but the more I think about this, I think the problem/solution is not CDO. Example, let's say I have a CDOResource which contains objects of type ECLASS = A. and has 10.000 objects, the only way to limit what is put in the viewer is:

1. Use the ILazyContentProvider (No databinding is possible, viewer doesn't suppor sorting/filtering).
2. Create a CDO Query (Which is unfortunately DB specific) which would give me a narrow down of the CDOResouce content and use regular databinding.

Observing the whole content of an EList is suboptimal, which is the regular usage advocated by Databinding.

noticed, that observing with an EMF List property makes a copy of the whole list when setInput() is called on the viewer! (No wonder it takes ages to load!).

something like this:

IEMFListProperty l = EMFEditProperties.resource(editingDomain);
IObservableList toleranceObservableList = l.observe(cdoResourceForA);


See this code below, which happens in SimplePropertyObservableList class (Which gets called somewhere in the databinding inheritance structure). The new ArraList makes the copy of the eContents from the CDOResource... auch....

getRealm().exec(new Runnable() {
				public void run() {
					cachedList = new ArrayList(getList());
					stale = false;

					if (listener != null)
						listener.addTo(source);
				}
			});



The real solution would be to have for Databinding, as it should support chunk based observing, and automatic attach and clear notifiers and that depends on the ability of the viewer to tell what is visible... (So should be partially observed). If the viewer would say, hey there is some scrolling, give me the next 60 objects, this would trigger a call to i.e.

cdoResourceForA.eContents().subList(fromIndex, toIndex)


With a CDO Prefetching policy matching the page size, it could be optimized to load exactly the content of one page in a single CDO round trip.... Smile

We have a situation where several technologies JFace Viewers, JFace databinding and CDO work together in a sub-optimal way. Perhaps there is an opportunity to fix this...

Christophe













Re: [CDO/SWT.Virtual] Virtual tables and CDOPrefetch [message #986636 is a reply to message #986624] Wed, 21 November 2012 09:27 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Hi Christophe,

I can't see why CDO's partial collection loading wouldn't be a perfect fit to implement ILazyContentProvider. The
visible list "page" wouldn't always exactly be what gets loaded but I doubt that this is normally necessary. With
partial collection loading you can access the entire list as if it was completely loaded but initially only the list
size and the first n IDs are loaded. Then, when you access any list element i > n, CDO will load another m missing IDs
around i. You can control m and n through the PCL policy in the session options.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Am 21.11.2012 10:00, schrieb Christophe Bouhier:
> Hi Eike,
> Lazy loading is really cool, but the more I think about this, I think the problem/solution is not CDO. Example, let's
> say I have a CDOResource which contains objects of type ECLASS = A. and has 10.000 objects, the only way to limit what
> is put in the viewer is:
> 1. Use the ILazyContentProvider (No databinding is possible, viewer doesn't suppor sorting/filtering). 2. Create a CDO
> Query (Which is unfortunately DB specific) which would give me a narrow down of the CDOResouce content and use regular
> databinding.
> Observing the whole content of an EList is suboptimal, which is the regular usage advocated by Databinding.
> noticed, that observing with an EMF List property makes a copy of the whole list when setInput() is called on the
> viewer! (No wonder it takes ages to load!).
> something like this:
> IEMFListProperty l = EMFEditProperties.resource(editingDomain);
> IObservableList toleranceObservableList = l.observe(cdoResourceForA);
>
>
> See this code below, which happens in SimplePropertyObservableList class (Which gets called somewhere in the
> databinding inheritance structure). The new ArraList makes the copy of the eContents from the CDOResource... auch....
> getRealm().exec(new Runnable() {
> public void run() {
> cachedList = new ArrayList(getList());
> stale = false;
>
> if (listener != null)
> listener.addTo(source);
> }
> });
>
>
> The real solution would be to have for Databinding, as it should support chunk based observing, and automatic attach
> and clear notifiers and that depends on the ability of the viewer to tell what is visible... (So should be partially
> observed). If the viewer would say, hey there is some scrolling, give me the next 60 objects, this would trigger a
> call to i.e.
> cdoResourceForA.eContents().subList(fromIndex, toIndex)
>
> With a CDO Prefetching policy matching the page size, it could be optimized to load exactly the content of one page in
> a single CDO round trip.... :)
>
> We have a situation where several technologies JFace Viewers, JFace databinding and CDO work together in a sub-optimal
> way. Perhaps there is an opportunity to fix this...
> Christophe
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Re: [CDO/SWT.Virtual] Virtual tables and CDOPrefetch [message #986654 is a reply to message #986636] Wed, 21 November 2012 10:06 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
Yes, I am not arguing against this, in contrary in views which do not need notifications I want to actually use it. The limitation however is that with the ILazyContentProvider I am not receiving notifications like Databinding would do. With EMF Edit Databinding, operations on the EditingDomain command stack would trigger notifications, if the UI component is not bound It won't update the viewer.
Re: [CDO/SWT.Virtual] Virtual tables and CDOPrefetch [message #986817 is a reply to message #986444] Wed, 21 November 2012 18:11 Go to previous messageGo to next message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 43
Registered: July 2009
Member
Christophe mentioned above something that would be nice to have:
object.cdoPrefetch(EStructuralFeature feature, ...)

We could even have this configured by Session, which means, when CDO is resolving the object of type A, it will always resolve the reference to B in the same query.

Could this be implemented (easily) in CDO?
This would give us a nice functionality similar to what Hibernate has, where you can prefetch what you want exactly, and solve the well known "Select N+1" problem.
Re: [CDO/SWT.Virtual] Virtual tables and CDOPrefetch [message #986865 is a reply to message #986817] Thu, 22 November 2012 07:26 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Am 21.11.2012 19:11, schrieb Silvestre Martins:
> Christophe mentioned above something that would be nice to have:
> object.cdoPrefetch(EStructuralFeature feature, ...)
You mean object.cdoPrefetch(int depth, EStructuralFeature... features)?

> We could even have this configured by Session, which means, when CDO is resolving the object of type A, it will always
> resolve the reference to B in the same query.
What about a 3-levels cascade of depending configurations: the model (through EAnnotations), the CDOSession and finally
the CDOView?

> Could this be implemented (easily) in CDO?
Yes, more or less easily. More a matter of effort, I guess.

> This would give us a nice functionality similar to what Hibernate has, where you can prefetch what you want exactly,
> and solve the well known "Select N+1" problem.
We already support user-provided prefetching policies. They just don't consider a particular feature but all contained
objects.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO/SWT.Virtual] Virtual tables and CDOPrefetch [message #986907 is a reply to message #986865] Thu, 22 November 2012 10:42 Go to previous messageGo to next message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 43
Registered: July 2009
Member
>> Christophe mentioned above something that would be nice to have:
>> object.cdoPrefetch(EStructuralFeature feature, ...)
> You mean object.cdoPrefetch(int depth, EStructuralFeature... features)?
Yes, something like that. As long the depth is not just making the same request recursively. The goal is to minimize the queries to the database.

>> We could even have this configured by Session, which means, when CDO is resolving the object of type A, it will always
>> resolve the reference to B in the same query.
> What about a 3-levels cascade of depending configurations: the model (through EAnnotations), the CDOSession and finally
> the CDOView?
That would be perfect!

>> Could this be implemented (easily) in CDO?
> Yes, more or less easily. More a matter of effort, I guess.
Well, I was in fact wondering if the effort would be too high...

>> This would give us a nice functionality similar to what Hibernate has, where you can prefetch what you want exactly,
>> and solve the well known "Select N+1" problem.
> We already support user-provided prefetching policies. They just don't consider a particular feature but all contained
> objects.

Ok, it can help already to solve this problem in some situations, even we load (unnecessarily) all contained objects.
But this won't solve the "Select N+1" problem completely, only reduces it: for a scenario where you have a collection of 100 A items and each of these contains a collection of 100 B items, then you reduce the following code from 10.000 queries to 100, but never to 1:
for (A a : root.getAs()) {
for (B b : a.getBs()) {
System.out.println(b.getId());
}
}

And if, instead you have 1000 A's and 10 B's in each A, then you only reduce it to 1000 queries.

Is there any way to solve this problem using these user-defined policies or the CDOFetchAnalyzer (unfortunately I'm not able to understand fully how this works, we need some more documentation and examples on the wiki, if someone is already using it).


> Cheers
> /Eike

> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
Re: [CDO/SWT.Virtual] Virtual tables and CDOPrefetch [message #986926 is a reply to message #986907] Thu, 22 November 2012 11:38 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Am 22.11.2012 11:42, schrieb Silvestre Martins:
>>> Christophe mentioned above something that would be nice to have:
>>> object.cdoPrefetch(EStructuralFeature feature, ...)
>> You mean object.cdoPrefetch(int depth, EStructuralFeature... features)?
> Yes, something like that. As long the depth is not just making the same request recursively. The goal is to minimize
> the queries to the database.
I think it's mostly to minimize the network signals between clients and server. I know of no way in, e.g., SQL to query
tree structures.

>
>>> We could even have this configured by Session, which means, when CDO is resolving the object of type A, it will
>>> always resolve the reference to B in the same query.
>> What about a 3-levels cascade of depending configurations: the model (through EAnnotations), the CDOSession and
>> finally the CDOView?
> That would be perfect!
>
>>> Could this be implemented (easily) in CDO?
>> Yes, more or less easily. More a matter of effort, I guess.
> Well, I was in fact wondering if the effort would be too high...
The question should be "for whom?" :P

>
>>> This would give us a nice functionality similar to what Hibernate has, where you can prefetch what you want exactly,
>>> and solve the well known "Select N+1" problem.
>> We already support user-provided prefetching policies. They just don't consider a particular feature but all
>> contained objects.
>
> Ok, it can help already to solve this problem in some situations, even we load (unnecessarily) all contained objects.
> But this won't solve the "Select N+1" problem completely, only reduces it: for a scenario where you have a collection
> of 100 A items and each of these contains a collection of 100 B items, then you reduce the following code from 10.000
> queries to 100, but never to 1:
> for (A a : root.getAs()) {
> for (B b : a.getBs()) {
> System.out.println(b.getId());
> }
> }
> And if, instead you have 1000 A's and 10 B's in each A, then you only reduce it to 1000 queries.
>
> Is there any way to solve this problem using these user-defined policies or the CDOFetchAnalyzer (unfortunately I'm
> not able to understand fully how this works, we need some more documentation and examples on the wiki, if someone is
> already using it).
This meachnism has been designed and implemented by someone who's not a committer anymore. I know a company i nthe
Netherlands who are using it. It's supposed to be very powerful and self-adapting to the current access patterns of the
application. But generically, not influenceable that much by users.
Re: [CDO/SWT.Virtual] Virtual tables and CDOPrefetch [message #986933 is a reply to message #986926] Thu, 22 November 2012 12:17 Go to previous messageGo to next message
Silvestre Martins is currently offline Silvestre MartinsFriend
Messages: 43
Registered: July 2009
Member
Eike Stepper wrote on Thu, 22 November 2012 06:38
Am 22.11.2012 11:42, schrieb Silvestre Martins:
>>> Christophe mentioned above something that would be nice to have:
>>> object.cdoPrefetch(EStructuralFeature feature, ...)
>> You mean object.cdoPrefetch(int depth, EStructuralFeature... features)?
> Yes, something like that. As long the depth is not just making the same request recursively. The goal is to minimize
> the queries to the database.
I think it's mostly to minimize the network signals between clients and server. I know of no way in, e.g., SQL to query
tree structures.


I'm not so sure about that. For example, the test I referred previously for the "Select N+1" problem, has a huge difference in executing with a local database or a remote database. I'm talking about 3 or 4 times slower when using a remote database.
And in this configuration, the client and CDO server are still in the same machine, so I don't expect different amount of traffic between client and CDO server regardless where the database is. So my conclusion is that the difference in the time comes exclusively from the time the CDO server takes to access the database.

Here are some profiling results on the SQL:
-> Without chunk prefetching:
-- self accu    time   count  result sql
--  37%  37%     840   10100   10100 SELECT cdo_class FROM cdo_objects WHERE cdo_id=?;
--  30%  68%     687   10117       0 ROLLBACK;
--  25%  93%     568   10000   10000 SELECT cdo_version, cdo_created, cdo_revised, cdo_resource, cdo_container, cdo_feature, objId FROM simpleTestModel_B WHERE cdo_id=?;
--   2%  96%      67     100   10000 SELECT cdo_value FROM simpleTestModel_A_bs_list WHERE cdo_source=?  ORDER BY cdo_idx;
--   1%  98%      41   10100   10100 SELECT uri FROM cdo_external_refs WHERE id=?;
--   0%  99%      20     100     100 SELECT cdo_version, cdo_created, cdo_revised, cdo_resource, cdo_container, cdo_feature, objId, bs FROM simpleTestModel_A WHERE cdo_id=?;
--   0%  99%       3       1     100 SELECT * FROM SIMPLETESTMODEL_A;

-------------------------------
-> With chunk prefetching (100 elements):
-- self accu    time   count  result sql
--  41%  41%     477   10000   10000 SELECT cdo_version, cdo_created, cdo_revised, cdo_resource, cdo_container, cdo_feature, objId FROM simpleTestModel_B WHERE cdo_id=?;
--  38%  79%     449   10100   10100 SELECT cdo_class FROM cdo_objects WHERE cdo_id=?;
--   8%  87%      93     100   10000 SELECT cdo_value FROM simpleTestModel_A_bs_list WHERE cdo_source=?  AND cdo_idx BETWEEN 0 AND 99 ORDER BY cdo_idx;
--   4%  92%      52     100     100 SELECT MIN(cdo_idx) FROM simpleTestModel_A_bs_list WHERE cdo_source=?;
--   3%  95%      43   10100   10100 SELECT uri FROM cdo_external_refs WHERE id=?;
--   2%  97%      24     317       0 ROLLBACK;
--   0%  98%      10     100     100 SELECT cdo_version, cdo_created, cdo_revised, cdo_resource, cdo_container, cdo_feature, objId, bs FROM simpleTestModel_A WHERE cdo_id=?;
--   0%  99%       3       1     100 SELECT * FROM SIMPLETESTMODEL_A;


And about SQL to query tree structures: is just a matter of joining tables in the same query.
In the example of A having a list of B, if I had a way to retrieve the list of A elements but also indicate that we want to load the list of B at same time, then the query to the database could already join A and A_bs_list in the select.
However, from what I saw, CDO always makes individual queries for a CDO_ID (or CDO_VALUE in the one-to-many table), and therefore will be constantly making a lot of queries to the DB.


Cheers,
Silvestre
Re: [CDO/SWT.Virtual] Virtual tables and CDOPrefetch [message #986939 is a reply to message #986933] Thu, 22 November 2012 12:44 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 5590
Registered: July 2009
Senior Member
Am 22.11.2012 13:17, schrieb Silvestre Martins:
> Eike Stepper wrote on Thu, 22 November 2012 06:38
>> Am 22.11.2012 11:42, schrieb Silvestre Martins:
>> >>> Christophe mentioned above something that would be nice to have:
>> >>> object.cdoPrefetch(EStructuralFeature feature, ...)
>> >> You mean object.cdoPrefetch(int depth, EStructuralFeature... features)?
>> > Yes, something like that. As long the depth is not just making the same request recursively. The goal is to
>> minimize > the queries to the database.
>> I think it's mostly to minimize the network signals between clients and server. I know of no way in, e.g., SQL to
>> query tree structures.
>
>
> I'm not so sure about that. For example, the test I referred previously for the "Select N+1" problem, has a huge
> difference in executing with a local database or a remote database. I'm talking about 3 or 4 times slower when using a
> remote database.
> And in this configuration, the client and CDO server are still in the same machine, so I don't expect different amount
> of traffic between client and CDO server regardless where the database is. So my conclusion is that the difference in
> the time comes exclusively from the time the CDO server takes to access the database.
I see, you're talking about the most rare deployment scenario: an embedded repository with a remote database. The most
common case is certainly a remote repository, with remote or embedded database.

It's absolutely clear that remote database access adds significantly to the query times. I just pointed out that that
part of the way is harder to optimize because it thinks in relations, not object trees.

>
> Here are some profiling results on the SQL:
> -> Without chunk prefetching:
> -- self accu time count result sql
> -- 37% 37% 840 10100 10100 SELECT cdo_class FROM cdo_objects WHERE cdo_id=?;
> -- 30% 68% 687 10117 0 ROLLBACK;
> -- 25% 93% 568 10000 10000 SELECT cdo_version, cdo_created, cdo_revised, cdo_resource, cdo_container,
> cdo_feature, objId FROM simpleTestModel_B WHERE cdo_id=?;
> -- 2% 96% 67 100 10000 SELECT cdo_value FROM simpleTestModel_A_bs_list WHERE cdo_source=? ORDER BY
> cdo_idx;
> -- 1% 98% 41 10100 10100 SELECT uri FROM cdo_external_refs WHERE id=?;
> -- 0% 99% 20 100 100 SELECT cdo_version, cdo_created, cdo_revised, cdo_resource, cdo_container,
> cdo_feature, objId, bs FROM simpleTestModel_A WHERE cdo_id=?;
> -- 0% 99% 3 1 100 SELECT * FROM SIMPLETESTMODEL_A;
> -------------------------------
> -> With chunk prefetching (100 elements):
> -- self accu time count result sql
> -- 41% 41% 477 10000 10000 SELECT cdo_version, cdo_created, cdo_revised, cdo_resource, cdo_container,
> cdo_feature, objId FROM simpleTestModel_B WHERE cdo_id=?;
> -- 38% 79% 449 10100 10100 SELECT cdo_class FROM cdo_objects WHERE cdo_id=?;
> -- 8% 87% 93 100 10000 SELECT cdo_value FROM simpleTestModel_A_bs_list WHERE cdo_source=? AND cdo_idx
> BETWEEN 0 AND 99 ORDER BY cdo_idx;
> -- 4% 92% 52 100 100 SELECT MIN(cdo_idx) FROM simpleTestModel_A_bs_list WHERE cdo_source=?;
> -- 3% 95% 43 10100 10100 SELECT uri FROM cdo_external_refs WHERE id=?;
> -- 2% 97% 24 317 0 ROLLBACK;
> -- 0% 98% 10 100 100 SELECT cdo_version, cdo_created, cdo_revised, cdo_resource, cdo_container,
> cdo_feature, objId, bs FROM simpleTestModel_A WHERE cdo_id=?;
> -- 0% 99% 3 1 100 SELECT * FROM SIMPLETESTMODEL_A;
>
>
> And about SQL to query tree structures: is just a matter of joining tables in the same query.
> In the example of A having a list of B, if I had a way to retrieve the list of A elements but also indicate that we
> want to load the list of B at same time, then the query to the database could already join A and A_bs_list in the select.
> However, from what I saw, CDO always makes individual queries for a CDO_ID (or CDO_VALUE in the one-to-many table),
> and therefore will be constantly making a lot of queries to the DB.
I thought that could need some optimization and we're certainly very happen if someone wants to contribute that.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Previous Topic:EcoreUtil.equals for xsd:list type
Next Topic:Customizing saving Model to XMI via XMISaveImpl options
Goto Forum:
  


Current Time: Sat Dec 20 18:39:39 GMT 2014

Powered by FUDForum. Page generated in 0.07361 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software