Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [CDO] Code Review for a faster Horizontal Mapping
| [CDO] Code Review for a faster Horizontal Mapping [message #1130094] |
Wed, 09 October 2013 08:19  |
 Christophe MOINE
Messages: 34
Registered: February 2012 |
Member |
|
|
Dear All,
We've been working on a new mapping strategy (with MySQL) to fix performance issues on 0-* references. It seems to work so far, but has a few drawbacks:
- It works only with containment features and the order is then not garanted (We rely on the cdo_containment column instead of the A_B_list table) For other features, we simply delegate to the standard mapping strategy.
- Major drawback: we cannot iterate over CDOResource.getContent(): we cannot read it, just write to it. It needs some adjustements in the applications, but it was not really blocking for us since we are widely using CDOView.createQuery(SQL, SQL_QUERY) method. I think we could easily make it work by delegating to the standard mapping strategy, otherwise we would need the check all cdo_resource of all tables... Simply awfull.
- The type of the containment feature must not be too generic  The more it is generic, the more table/cdo_contaiment we need to check (this is the same problem as previously)
The advantages are the following:
- We don't bother with the order of containment feature which seriously improve performances.
- Remove redunduncy between A_B_list and the cdo_containment column if we don't mind about order (we have a few of DB corruption, this is less to repair then)
- Using the cdo_contament instead of the A_B_list is simply more Relationnal DB compliant in my point of view.
We would like to port this principle for non containment features, but this is more tricky. We would need an additionnal column (equivalent to cdo_containment) to replace the A_B_list table.
We haven't done serious benchmarking so far even if the gain is notifiable. I can try to do that if you are interested with this.
Before sending this into production, we would appreciate a lot some code review on the NonAuditListTableMapping2 especially.
Thank you in advance for your comments,
Cheers,
Christophe.
|
|
|
| Re: [CDO] Code Review for a faster Horizontal Mapping [message #1130585 is a reply to message #1130094] |
Wed, 09 October 2013 18:30  |
|
Hi Christoph,
CDO topics should be discussed in the EMF newsgroup, which I've added to this conversation.
It sounds as if you've invested considerable analysis and development effort into this new list mapping, even if it
seems a bit incomplete and even if there are (still?) some drawbacks. So I will want to look more closely at your code,
but right now is a bad time for me because I'm with a customer this week and that's pretty exhaustive already. I suggest
that you submit a bugzilla and attach your changes in form of a workspace patch for easier application. Until I come to
review it you can easily add new patches when you have more changes.
That said, it strikes me that some of the restrictions you outline below are hard to accept (some even hard to
understand), e.g. not being able to read a collection while you can write to it.
To make it easier to test your mapping it would be nice to also patch the typical test scenario IConfigs so that we can
run the regression tests.
So much for now in my limited time ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 09.10.2013 10:19, schrieb Christophe MOINE:
> Dear All,
>
> We've been working on a new mapping strategy (with MySQL) to fix performance issues on 0-* references. It seems to work so far, but has a few drawbacks:
> - It works only with containment features and the order is then not garanted (We rely on the cdo_containment column instead of the A_B_list table) For other features, we simply delegate to the standard mapping strategy.
> - Major drawback: we cannot iterate over CDOResource.getContent(): we cannot read it, just write to it. It needs some adjustements in the applications, but it was not really blocking for us since we are widely using CDOView.createQuery(SQL, SQL_QUERY) method. I think we could easily make it work by delegating to the standard mapping strategy, otherwise we would need the check all cdo_resource of all tables... Simply awfull.
> - The type of the containment feature must not be too generic :o The more it is generic, the more table/cdo_contaiment we need to check (this is the same problem as previously)
>
> The advantages are the following:
> - We don't bother with the order of containment feature which seriously improve performances.
> - Remove redunduncy between A_B_list and the cdo_containment column if we don't mind about order (we have a few of DB corruption, this is less to repair then)
> - Using the cdo_contament instead of the A_B_list is simply more Relationnal DB compliant in my point of view.
>
> We would like to port this principle for non containment features, but this is more tricky. We would need an additionnal column (equivalent to cdo_containment) to replace the A_B_list table.
>
> We haven't done serious benchmarking so far even if the gain is notifiable. I can try to do that if you are interested with this.
>
> Before sending this into production, we would appreciate a lot some code review on the NonAuditListTableMapping2 especially.
>
> Thank you in advance for your comments,
>
> Cheers,
>
> Christophe.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | |
Goto Forum:
Current Time: Fri Apr 19 22:34:15 GMT 2024
Powered by FUDForum. Page generated in 0.03353 seconds |
] 
Search
Help
Register
Login
Home
