Home » Modeling » EMF » [CDO] EFeatureMap support in DBStore
| |
Re: [CDO] EFeatureMap support in DBStore [message #430986 is a reply to message #430979] |
Tue, 23 June 2009 07:17 |
Stefan Winkler Messages: 307 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;">> 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</span>
>
<span class="quote" style="color: rgb(101, 55, 156); white-space: pre;">> The new DBStore structure which I introduced can be extended quite easily for
> this.</span>
>
>
<span class="quote" style="color: rgb(101, 55, 156); white-space: pre;">> The bad news:</span>
>
<span class="quote" style="color: rgb(101, 55, 156); white-space: pre;">> 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. </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 <null><br>
1 1 bar <null> 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 07:32 |
Thomas Schindl Messages: 6651 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 10:02 |
|
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
>>
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] EFeatureMap support in DBStore [message #430996 is a reply to message #430986] |
Tue, 23 June 2009 17:13 |
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 07:31 |
Stefan Winkler Messages: 307 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 07:42 |
Stefan Winkler Messages: 307 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 10:38 |
|
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--
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Re: [CDO] EFeatureMap support in DBStore [message #431043 is a reply to message #431012] |
Thu, 25 June 2009 07:06 |
Stefan Winkler Messages: 307 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
>>>
>>>
>>>
|
|
|
Goto Forum:
Current Time: Wed Sep 25 18:27:06 GMT 2024
Powered by FUDForum. Page generated in 0.04230 seconds
|