Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] EFeatureMap support in DBStore
[CDO] EFeatureMap support in DBStore [message #430979] Mon, 22 June 2009 13:33 Go to next message
Christopher Albert is currently offline Christopher Albert
Messages: 5
Registered: July 2009
Junior Member
Hi!

We are currently migrating an Eclipse plugin to a CDO backend at Graz
University of Technology and are having problems persisting XSD-based
models because of EFeatureMap not being implemented in the DBStore
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=254455):

[ERROR] Rollback in DBStore: org.eclipse.net4j.util.ImplementationError:
Unrecognized CDOType: FEATURE_MAP_ENTRY

Do you know when this feature will be available and how much work it is to
implement it? If we could get some documentation to the design of DBStore
and the main difficulties, we could maybe try to implement it ourselves?

Thanks and

best regards,

Christopher Albert
Re: [CDO] EFeatureMap support in DBStore [message #430982 is a reply to message #430979] Mon, 22 June 2009 15:25 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5486
Registered: July 2009
Senior Member
Christopher,

I hope that Stefan can jump in for this question...

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Christopher Albert schrieb:
> Hi!
>
> We are currently migrating an Eclipse plugin to a CDO backend at Graz
> University of Technology and are having problems persisting XSD-based
> models because of EFeatureMap not being implemented in the DBStore
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=254455):
>
> [ERROR] Rollback in DBStore: org.eclipse.net4j.util.ImplementationError:
> Unrecognized CDOType: FEATURE_MAP_ENTRY
>
> Do you know when this feature will be available and how much work it
> is to implement it? If we could get some documentation to the design
> of DBStore and the main difficulties, we could maybe try to implement
> it ourselves?
>
> Thanks and
>
> best regards,
>
> Christopher Albert
>
>
Re: [CDO] EFeatureMap support in DBStore [message #430986 is a reply to message #430979] Tue, 23 June 2009 03:17 Go to previous messageGo to next message
Stefan Winkler is currently offline Stefan Winkler
Messages: 277
Registered: July 2009
Location: Germany
Senior Member
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
Christopher Albert schrieb:
<blockquote
cite="mid:7130a96a92784e60707256bdcba400c4$1@www.eclipse.org"
type="cite">Hi!
<br>
<br>
We are currently migrating an Eclipse plugin to a CDO backend at Graz
University of Technology and are having problems persisting XSD-based
models because of EFeatureMap not being implemented in the DBStore
(<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=254455">https://bugs.eclipse.org/bugs/show_bug.cgi?id=254455</a>):
<br>
<br>
[ERROR] Rollback in DBStore:
org.eclipse.net4j.util.ImplementationError:
<br>
Unrecognized CDOType: FEATURE_MAP_ENTRY
<br>
<br>
Do you know when this feature will be available and how much work it is
to implement it? If we could get some documentation to the design of
DBStore and the main difficulties, we could maybe try to implement it
ourselves?
<br>
</blockquote>
I had a comment on this on Bug 249436. I just copied it over to 254455
so the information is all in one place:<br>
<br>
<span class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'times new roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;"><span
class="Apple-style-span"
style="font-family: -webkit-sans-serif; font-size: 13px;">
<form name="changeform" method="post" action="process_bug.cgi">
<div id="comments">
<div class="bz_comment" style="margin-bottom: 2em;">
<pre class="bz_comment_text" id="comment_text_8"
style="font-family: monospace; width: 50em;"><span class="quote"
style="color: rgb(101, 55, 156); white-space: pre;">&gt; The good news:
&gt;
&gt; It is not so much effort to implement FeatureMaps in the DBStore.
&gt; I have already agreed with Eike on how to do it:
&gt; - Define a new mapping which works similar to the ListMapping,
&gt; - but with one column containing the tag (which feature are we storing)
&gt; - and one column for each feature</span>
&gt;
<span class="quote" style="color: rgb(101, 55, 156); white-space: pre;">&gt; The new DBStore structure which I introduced can be extended quite easily for
&gt; this.</span>
&gt;
&gt;
<span class="quote" style="color: rgb(101, 55, 156); white-space: pre;">&gt; The bad news:</span>
&gt;
<span class="quote" style="color: rgb(101, 55, 156); white-space: pre;">&gt; I just don't have much time currently. If you really need the feature, maybe
&gt; you are willing to invest some time (1-2 days) to create the implementation. </span>
</pre>
</div>
</div>
</form>
</span></span>So please do go ahead and try implementing it yourself. I
will be glad to give support via email or Skype. <br>
<br>
A good place to start is looking at the DBStore, in particular at the
ListMappings and the HorizontalMappingStrategy which is the factory for
the ListMappings.<br>
From there, a new class FeatureMapMapping or something like this should
be implemented, which would at first work something like this:<br>
<br>
If a EFeatureMapEntry has two entries "hello" and "world" for two
different features "foo" and "bar" then the table could look like this:<br>
<br>
cdo_id   index   tag   value_foo   value_bar<br>
1            0         foo   hello         &lt;null&gt;<br>
1            1         bar   &lt;null&gt;      world<br>
<br>
so the mapping would be:<br>
- at init time: for every EStructuralFeature create a column with its
name<br>
- at runtime for every FM-Entry create a row (as in ListMapping) but
instead of the simple value set the tag column to the
EStructuralFeature.getName() and the corresponding value column to the
actual value.<br>
<br>
An advanced mapping which is more desirable (because it takes up less
space) is:<br>
- at init time: for every unique EStructuralFeature.getType() create a
column <br>
- at runtime: map entry to row as above, but set the actual value to
the column determined by EStructuralFeature.getType()<br>
<br>
cdo_id   index   tag   value_string<br>
1            0         foo   hello         <br>
1            1         bar   world<br>
<br>
If you want to directly implement the second mapping, the better ;-)<br>
<br>
As I said, if you have more questions, I'll be happy to answer them and
support your implementation effort!<br>
<br>
Cheers,<br>
Stefan<br>
<br>
</body>
</html>
Re: [CDO] EFeatureMap support in DBStore [message #430987 is a reply to message #430986] Tue, 23 June 2009 03:32 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5259
Registered: July 2009
Senior Member
Hi,

The other option might be to check if the Teneo-Backend is working for
the model (or probably investing some hours to bring it uptodate - IIRC
Martin said once he has time he's going to look into the current test
failures) because Teneo supports feature maps.

Because Teneo-Support is quite high on my list of needed CDO-stuff in
the next half year, I might take a look into it myself hopefully soon
but I can't promise.

Tom

Stefan Winkler schrieb:
> Hi,
>
> Christopher Albert schrieb:
>> Hi!
>>
>> We are currently migrating an Eclipse plugin to a CDO backend at Graz
>> University of Technology and are having problems persisting XSD-based
>> models because of EFeatureMap not being implemented in the DBStore
>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=254455):
>>
>> [ERROR] Rollback in DBStore: org.eclipse.net4j.util.ImplementationError:
>> Unrecognized CDOType: FEATURE_MAP_ENTRY
>>
>> Do you know when this feature will be available and how much work it
>> is to implement it? If we could get some documentation to the design
>> of DBStore and the main difficulties, we could maybe try to implement
>> it ourselves?
> I had a comment on this on Bug 249436. I just copied it over to 254455
> so the information is all in one place:
>
>> The good news:
>>
>> It is not so much effort to implement FeatureMaps in the DBStore.
>> I have already agreed with Eike on how to do it:
>> - Define a new mapping which works similar to the ListMapping,
>> - but with one column containing the tag (which feature are we storing)
>> - and one column for each feature
>>
>> The new DBStore structure which I introduced can be extended quite easily for
>> this.
>>
>>
>> The bad news:
>>
>> I just don't have much time currently. If you really need the feature, maybe
>> you are willing to invest some time (1-2 days) to create the implementation.
>
>
> So please do go ahead and try implementing it yourself. I will be glad
> to give support via email or Skype.
>
> A good place to start is looking at the DBStore, in particular at the
> ListMappings and the HorizontalMappingStrategy which is the factory for
> the ListMappings.
> From there, a new class FeatureMapMapping or something like this should
> be implemented, which would at first work something like this:
>
> If a EFeatureMapEntry has two entries "hello" and "world" for two
> different features "foo" and "bar" then the table could look like this:
>
> cdo_id index tag value_foo value_bar
> 1 0 foo hello <null>
> 1 1 bar <null> world
>
> so the mapping would be:
> - at init time: for every EStructuralFeature create a column with its name
> - at runtime for every FM-Entry create a row (as in ListMapping) but
> instead of the simple value set the tag column to the
> EStructuralFeature.getName() and the corresponding value column to the
> actual value.
>
> An advanced mapping which is more desirable (because it takes up less
> space) is:
> - at init time: for every unique EStructuralFeature.getType() create a
> column
> - at runtime: map entry to row as above, but set the actual value to the
> column determined by EStructuralFeature.getType()
>
> cdo_id index tag value_string
> 1 0 foo hello
> 1 1 bar world
>
> If you want to directly implement the second mapping, the better ;-)
>
> As I said, if you have more questions, I'll be happy to answer them and
> support your implementation effort!
>
> Cheers,
> Stefan
>
Re: [CDO] EFeatureMap support in DBStore [message #430988 is a reply to message #430987] Tue, 23 June 2009 06:02 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5486
Registered: July 2009
Senior Member
Tom Schindl schrieb:
> Hi,
>
> The other option might be to check if the Teneo-Backend is working for
> the model (or probably investing some hours to bring it uptodate - IIRC
> Martin said once he has time he's going to look into the current test
> failures) because Teneo supports feature maps.
>
> Because Teneo-Support is quite high on my list of needed CDO-stuff in
> the next half year, I might take a look into it myself hopefully soon
> but I can't promise.
>
Hey, we'd love to finally welcome you as a CDO committer! ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


> Tom
>
> Stefan Winkler schrieb:
>
>> Hi,
>>
>> Christopher Albert schrieb:
>>
>>> Hi!
>>>
>>> We are currently migrating an Eclipse plugin to a CDO backend at Graz
>>> University of Technology and are having problems persisting XSD-based
>>> models because of EFeatureMap not being implemented in the DBStore
>>> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=254455):
>>>
>>> [ERROR] Rollback in DBStore: org.eclipse.net4j.util.ImplementationError:
>>> Unrecognized CDOType: FEATURE_MAP_ENTRY
>>>
>>> Do you know when this feature will be available and how much work it
>>> is to implement it? If we could get some documentation to the design
>>> of DBStore and the main difficulties, we could maybe try to implement
>>> it ourselves?
>>>
>> I had a comment on this on Bug 249436. I just copied it over to 254455
>> so the information is all in one place:
>>
>>
>>> The good news:
>>>
>>> It is not so much effort to implement FeatureMaps in the DBStore.
>>> I have already agreed with Eike on how to do it:
>>> - Define a new mapping which works similar to the ListMapping,
>>> - but with one column containing the tag (which feature are we storing)
>>> - and one column for each feature
>>>
>>> The new DBStore structure which I introduced can be extended quite easily for
>>> this.
>>>
>>>
>>> The bad news:
>>>
>>> I just don't have much time currently. If you really need the feature, maybe
>>> you are willing to invest some time (1-2 days) to create the implementation.
>>>
>>
>>
>> So please do go ahead and try implementing it yourself. I will be glad
>> to give support via email or Skype.
>>
>> A good place to start is looking at the DBStore, in particular at the
>> ListMappings and the HorizontalMappingStrategy which is the factory for
>> the ListMappings.
>> From there, a new class FeatureMapMapping or something like this should
>> be implemented, which would at first work something like this:
>>
>> If a EFeatureMapEntry has two entries "hello" and "world" for two
>> different features "foo" and "bar" then the table could look like this:
>>
>> cdo_id index tag value_foo value_bar
>> 1 0 foo hello <null>
>> 1 1 bar <null> world
>>
>> so the mapping would be:
>> - at init time: for every EStructuralFeature create a column with its name
>> - at runtime for every FM-Entry create a row (as in ListMapping) but
>> instead of the simple value set the tag column to the
>> EStructuralFeature.getName() and the corresponding value column to the
>> actual value.
>>
>> An advanced mapping which is more desirable (because it takes up less
>> space) is:
>> - at init time: for every unique EStructuralFeature.getType() create a
>> column
>> - at runtime: map entry to row as above, but set the actual value to the
>> column determined by EStructuralFeature.getType()
>>
>> cdo_id index tag value_string
>> 1 0 foo hello
>> 1 1 bar world
>>
>> If you want to directly implement the second mapping, the better ;-)
>>
>> As I said, if you have more questions, I'll be happy to answer them and
>> support your implementation effort!
>>
>> Cheers,
>> Stefan
>>
>>
Re: [CDO] EFeatureMap support in DBStore [message #430996 is a reply to message #430986] Tue, 23 June 2009 13:13 Go to previous messageGo to next message
Christopher Albert is currently offline Christopher Albert
Messages: 5
Registered: July 2009
Junior Member
Thank you for the quick reply!

Stefan Winkler schrieb:
>
> So please do go ahead and try implementing it yourself. I will be glad
> to give support via email or Skype.

Thanks, I've just added you on Skype.

>
> A good place to start is looking at the DBStore, in particular at the
> ListMappings and the HorizontalMappingStrategy which is the factory for
> the ListMappings.

I've browsed throught the code, it looks clean and easy to understand :D


> From there, a new class FeatureMapMapping or something like this should
> be implemented, which would at first work something like this:
> If a EFeatureMapEntry has two entries "hello" and "world" for two
> different features "foo" and "bar" then the table could look like this:
>
> cdo_id index tag value_foo value_bar
> 1 0 foo hello <null>
> 1 1 bar <null> world
>
> so the mapping would be:
> - at init time: for every EStructuralFeature create a column with its name
> - at runtime for every FM-Entry create a row (as in ListMapping) but
> instead of the simple value set the tag column to the
> EStructuralFeature.getName() and the corresponding value column to the
> actual value.
>
> An advanced mapping which is more desirable (because it takes up less
> space) is:
> - at init time: for every unique EStructuralFeature.getType() create a
> column
> - at runtime: map entry to row as above, but set the actual value to the
> column determined by EStructuralFeature.getType()
>
> cdo_id index tag value_string
> 1 0 foo hello
> 1 1 bar world
>
> If you want to directly implement the second mapping, the better ;-)

OK, I will implement the second one if you think it's better.
But if I have understood correctly (I'm no DB-developer and also quite
new to EMF), the first one has the advantage that you can use other
DB-field types than strings, I think this will add some performance
overhead (apart from the problem to map everything to strings).

A third option would be to generate multiple list tables, one for each
tag, and join them when needed. What do you think about that?

> As I said, if you have more questions, I'll be happy to answer them and
> support your implementation effort!
>

I'd be very glad!

regards,
Chris
Re: [CDO] EFeatureMap support in DBStore [message #431007 is a reply to message #430996] Wed, 24 June 2009 03:31 Go to previous messageGo to next message
Stefan Winkler is currently offline Stefan Winkler
Messages: 277
Registered: July 2009
Location: Germany
Senior Member
Hi,

Comments below.
>> An advanced mapping which is more desirable (because it takes up less
>> space) is:
>> - at init time: for every unique EStructuralFeature.getType() create
>> a column
>> - at runtime: map entry to row as above, but set the actual value to
>> the column determined by EStructuralFeature.getType()
>>
>> cdo_id index tag value_string
>> 1 0 foo hello 1 1
>> bar world
>>
>> If you want to directly implement the second mapping, the better ;-)
>
> OK, I will implement the second one if you think it's better.
> But if I have understood correctly (I'm no DB-developer and also quite
> new to EMF), the first one has the advantage that you can use other
> DB-field types than strings, I think this will add some performance
> overhead (apart from the problem to map everything to strings).
Ok, my second example was too simple ;). I meant one column for each
type. The difference to the first mapping is that one column is created
for each EStructuralFeature which can be contained in the feature map.
In the second mapping, we only create one column for each distinct
feature type.
So, if you have mixed type, as in this (first) mapping

cdo_id
index
tag
value_foo
value_bar
value_count
1
0
foo
hello


1
1
bar

world

1
2
count


1


you would get (in the second mapping):

cdo_id
index
tag
value_string
value_int
1
0
foo
hello

1
1
bar
world

1
2
count

1



>
> A third option would be to generate multiple list tables, one for each
> tag, and join them when needed. What do you think about that?
The problem with that is that reading and updating (moving, inserting,
deleting -- at least in non-audit mode) gets a lot more complicated,
because then the indexes are scattered among different tables. I had
discussed that with Eike, too, but as far as I remember that solution
introduces more problems than it solves.

Cheers,
Stefan
Re: [CDO] EFeatureMap support in DBStore [message #431008 is a reply to message #431007] Wed, 24 June 2009 03:42 Go to previous messageGo to next message
Stefan Winkler is currently offline Stefan Winkler
Messages: 277
Registered: July 2009
Location: Germany
Senior Member
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Sorry, the example tables were messed up.<br>
<br>
Below is the next try ...<br>
<br>
Stefan Winkler schrieb:
<blockquote cite="mid:4A41D667.8010704@fernuni-hagen.de" type="cite">
<pre wrap="">Hi,

Comments below.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">An advanced mapping which is more desirable (because it takes up less
space) is:
- at init time: for every unique EStructuralFeature.getType() create
a column
- at runtime: map entry to row as above, but set the actual value to
the column determined by EStructuralFeature.getType()

cdo_id index tag value_string
1 0 foo hello 1 1
bar world

If you want to directly implement the second mapping, the better ;-)
</pre>
</blockquote>
<pre wrap="">OK, I will implement the second one if you think it's better.
But if I have understood correctly (I'm no DB-developer and also quite
new to EMF), the first one has the advantage that you can use other
DB-field types than strings, I think this will add some performance
overhead (apart from the problem to map everything to strings).
</pre>
</blockquote>
<pre wrap=""><!---->Ok, my second example was too simple ;). I meant one column for each
type. The difference to the first mapping is that one column is created
for each EStructuralFeature which can be contained in the feature map.
In the second mapping, we only create one column for each distinct
feature type.
So, if you have mixed type, as in this (first) mapping
</pre>
</blockquote>
<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">cdo_id<br>
</td>
<td valign="top">index<br>
</td>
<td valign="top">tag<br>
</td>
<td valign="top">value_foo</td>
<td valign="top">value_bar<br>
</td>
<td valign="top">value_count<br>
</td>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">foo<br>
</td>
<td valign="top">hello<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">1<br>
</td>
<td valign="top">bar<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">world<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">2<br>
</td>
<td valign="top">count<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top">1<br>
</td>
</tr>
</tbody>
</table>
<br>
.... you would get (in the second mapping):<br>
<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">cdo_id<br>
</td>
<td valign="top">index<br>
</td>
<td valign="top">tag<br>
</td>
<td valign="top">value_string</td>
<td valign="top">value_int<br>
</td>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">foo<br>
</td>
<td valign="top">hello<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">1<br>
</td>
<td valign="top">bar<br>
</td>
<td valign="top">world<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">2<br>
</td>
<td valign="top">count<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">1<br>
</td>
</tr>
</tbody>
</table>
<br>
<blockquote cite="mid:4A41D667.8010704@fernuni-hagen.de" type="cite">
<blockquote type="cite">
<pre wrap="">A third option would be to generate multiple list tables, one for each
tag, and join them when needed. What do you think about that?
</pre>
</blockquote>
<pre wrap=""><!---->The problem with that is that reading and updating (moving, inserting,
deleting -- at least in non-audit mode) gets a lot more complicated,
because then the indexes are scattered among different tables. I had
discussed that with Eike, too, but as far as I remember that solution
introduces more problems than it solves.

Cheers,
Stefan


</pre>
</blockquote>
</body>
</html>
Re: [CDO] EFeatureMap support in DBStore [message #431012 is a reply to message #431008] Wed, 24 June 2009 06:38 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5486
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------040602010501060409000000
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Guys,

One mapping looks a bit more space preserving, while the other seems to
be easier to query with SQL. What about making this configurable?

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Stefan Winkler schrieb:
> Sorry, the example tables were messed up.
>
> Below is the next try ...
>
> Stefan Winkler schrieb:
>> Hi,
>>
>> Comments below.
>>
>>>> An advanced mapping which is more desirable (because it takes up less
>>>> space) is:
>>>> - at init time: for every unique EStructuralFeature.getType() create
>>>> a column
>>>> - at runtime: map entry to row as above, but set the actual value to
>>>> the column determined by EStructuralFeature.getType()
>>>>
>>>> cdo_id index tag value_string
>>>> 1 0 foo hello 1 1
>>>> bar world
>>>>
>>>> If you want to directly implement the second mapping, the better ;-)
>>>>
>>> OK, I will implement the second one if you think it's better.
>>> But if I have understood correctly (I'm no DB-developer and also quite
>>> new to EMF), the first one has the advantage that you can use other
>>> DB-field types than strings, I think this will add some performance
>>> overhead (apart from the problem to map everything to strings).
>>>
>> Ok, my second example was too simple ;). I meant one column for each
>> type. The difference to the first mapping is that one column is created
>> for each EStructuralFeature which can be contained in the feature map.
>> In the second mapping, we only create one column for each distinct
>> feature type.
>> So, if you have mixed type, as in this (first) mapping
>>
>
> cdo_id
> index
> tag
> value_foo value_bar
> value_count
> 1
> 0
> foo
> hello
>
>
> 1
> 1
> bar
>
> world
>
> 1
> 2
> count
>
>
> 1
>
>
> .... you would get (in the second mapping):
>
> cdo_id
> index
> tag
> value_string value_int
> 1
> 0
> foo
> hello
>
> 1
> 1
> bar
> world
>
> 1
> 2
> count
>
> 1
>
>
>>> A third option would be to generate multiple list tables, one for each
>>> tag, and join them when needed. What do you think about that?
>>>
>> The problem with that is that reading and updating (moving, inserting,
>> deleting -- at least in non-audit mode) gets a lot more complicated,
>> because then the indexes are scattered among different tables. I had
>> discussed that with Eike, too, but as far as I remember that solution
>> introduces more problems than it solves.
>>
>> Cheers,
>> Stefan
>>
>>
>>

--------------040602010501060409000000
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Guys,<br>
<br>
One mapping looks a bit more space preserving, while the other seems to
be easier to query with SQL. What about making this configurable?<br>
<br>
Cheers<br>
/Eike<br>
<br>
----<br>
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a><br>
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a><br>
<br>
<br>
<br>
Stefan Winkler schrieb:
<blockquote cite="mid:4A41D8EA.1080405@fernuni-hagen.de" type="cite">
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
Sorry, the example tables were messed up.<br>
<br>
Below is the next try ...<br>
<br>
Stefan Winkler schrieb:
<blockquote cite="mid:4A41D667.8010704@fernuni-hagen.de" type="cite">
<pre wrap="">Hi,

Comments below.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">An advanced mapping which is more desirable (because it takes up less
space) is:
- at init time: for every unique EStructuralFeature.getType() create
a column
- at runtime: map entry to row as above, but set the actual value to
the column determined by EStructuralFeature.getType()

cdo_id index tag value_string
1 0 foo hello 1 1
bar world

If you want to directly implement the second mapping, the better ;-)
</pre>
</blockquote>
<pre wrap="">OK, I will implement the second one if you think it's better.
But if I have understood correctly (I'm no DB-developer and also quite
new to EMF), the first one has the advantage that you can use other
DB-field types than strings, I think this will add some performance
overhead (apart from the problem to map everything to strings).
</pre>
</blockquote>
<pre wrap=""><!---->Ok, my second example was too simple ;). I meant one column for each
type. The difference to the first mapping is that one column is created
for each EStructuralFeature which can be contained in the feature map.
In the second mapping, we only create one column for each distinct
feature type.
So, if you have mixed type, as in this (first) mapping
</pre>
</blockquote>
<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">cdo_id<br>
</td>
<td valign="top">index<br>
</td>
<td valign="top">tag<br>
</td>
<td valign="top">value_foo</td>
<td valign="top">value_bar<br>
</td>
<td valign="top">value_count<br>
</td>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">foo<br>
</td>
<td valign="top">hello<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">1<br>
</td>
<td valign="top">bar<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">world<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">2<br>
</td>
<td valign="top">count<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top">1<br>
</td>
</tr>
</tbody>
</table>
<br>
..... you would get (in the second mapping):<br>
<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">cdo_id<br>
</td>
<td valign="top">index<br>
</td>
<td valign="top">tag<br>
</td>
<td valign="top">value_string</td>
<td valign="top">value_int<br>
</td>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">foo<br>
</td>
<td valign="top">hello<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">1<br>
</td>
<td valign="top">bar<br>
</td>
<td valign="top">world<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">1<br>
</td>
<td valign="top">2<br>
</td>
<td valign="top">count<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">1<br>
</td>
</tr>
</tbody>
</table>
<br>
<blockquote cite="mid:4A41D667.8010704@fernuni-hagen.de" type="cite">
<blockquote type="cite">
<pre wrap="">A third option would be to generate multiple list tables, one for each
tag, and join them when needed. What do you think about that?
</pre>
</blockquote>
<pre wrap=""><!---->The problem with that is that reading and updating (moving, inserting,
deleting -- at least in non-audit mode) gets a lot more complicated,
because then the indexes are scattered among different tables. I had
discussed that with Eike, too, but as far as I remember that solution
introduces more problems than it solves.

Cheers,
Stefan


</pre>
</blockquote>
</blockquote>
</body>
</html>

--------------040602010501060409000000--
Re: [CDO] EFeatureMap support in DBStore [message #431013 is a reply to message #430979] Wed, 24 June 2009 06:55 Go to previous messageGo to next message
Christopher Albert is currently offline Christopher Albert
Messages: 5
Registered: July 2009
Junior Member
Christopher Albert schrieb:
> Hi!
>
> We are currently migrating an Eclipse plugin to a CDO backend at Graz
> University of Technology and are having problems persisting XSD-based
> models because of EFeatureMap not being implemented in the DBStore
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=254455):
>
> [ERROR] Rollback in DBStore: org.eclipse.net4j.util.ImplementationError:
> Unrecognized CDOType: FEATURE_MAP_ENTRY
>
> Do you know when this feature will be available and how much work it is
> to implement it? If we could get some documentation to the design of
> DBStore and the main difficulties, we could maybe try to implement it
> ourselves?
>
> Thanks and
>
> best regards,
>
> Christopher Albert
>
>
I've updated the bug and aded a patch with basic FeatureMap support in
audit mode.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=254455

cheers,

Chris
Re: [CDO] EFeatureMap support in DBStore [message #431043 is a reply to message #431012] Thu, 25 June 2009 03:06 Go to previous message
Stefan Winkler is currently offline Stefan Winkler
Messages: 277
Registered: July 2009
Location: Germany
Senior Member
Hi,
> One mapping looks a bit more space preserving, while the other seems
> to be easier to query with SQL. What about making this configurable?
No problem - after one implementation is finished, we can refactor
common code into a abstract superclass and then implement the other
mapping based on that.
Configuration happend through MappingStrategy (which is the factory for
the mappings). On the long term, this even allows for
per-class-configuration.

Cheers,
Stefan


>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Stefan Winkler schrieb:
>> Sorry, the example tables were messed up.
>>
>> Below is the next try ...
>>
>> Stefan Winkler schrieb:
>>> Hi,
>>>
>>> Comments below.
>>>
>>>>> An advanced mapping which is more desirable (because it takes up less
>>>>> space) is:
>>>>> - at init time: for every unique EStructuralFeature.getType() create
>>>>> a column
>>>>> - at runtime: map entry to row as above, but set the actual value to
>>>>> the column determined by EStructuralFeature.getType()
>>>>>
>>>>> cdo_id index tag value_string
>>>>> 1 0 foo hello 1 1
>>>>> bar world
>>>>>
>>>>> If you want to directly implement the second mapping, the better ;-)
>>>>>
>>>> OK, I will implement the second one if you think it's better.
>>>> But if I have understood correctly (I'm no DB-developer and also quite
>>>> new to EMF), the first one has the advantage that you can use other
>>>> DB-field types than strings, I think this will add some performance
>>>> overhead (apart from the problem to map everything to strings).
>>>>
>>> Ok, my second example was too simple ;). I meant one column for each
>>> type. The difference to the first mapping is that one column is created
>>> for each EStructuralFeature which can be contained in the feature map.
>>> In the second mapping, we only create one column for each distinct
>>> feature type.
>>> So, if you have mixed type, as in this (first) mapping
>>>
>>
>> cdo_id
>> index
>> tag
>> value_foo value_bar
>> value_count
>> 1
>> 0
>> foo
>> hello
>>
>>
>> 1
>> 1
>> bar
>>
>> world
>>
>> 1
>> 2
>> count
>>
>>
>> 1
>>
>>
>> .... you would get (in the second mapping):
>>
>> cdo_id
>> index
>> tag
>> value_string value_int
>> 1
>> 0
>> foo
>> hello
>>
>> 1
>> 1
>> bar
>> world
>>
>> 1
>> 2
>> count
>>
>> 1
>>
>>
>>>> A third option would be to generate multiple list tables, one for each
>>>> tag, and join them when needed. What do you think about that?
>>>>
>>> The problem with that is that reading and updating (moving, inserting,
>>> deleting -- at least in non-audit mode) gets a lot more complicated,
>>> because then the indexes are scattered among different tables. I had
>>> discussed that with Eike, too, but as far as I remember that solution
>>> introduces more problems than it solves.
>>>
>>> Cheers,
>>> Stefan
>>>
>>>
>>>
Previous Topic:galileo there but cdo and net4j not?
Next Topic:seems like an "unsettable"-related serialization issue
Goto Forum:
  


Current Time: Thu Jul 31 17:45:26 EDT 2014

Powered by FUDForum. Page generated in 0.04565 seconds