Home » Modeling » EMF » [CDO] Hacking CDO to add an ability to search for commits affecting eObject or it's containments(Guidance need)
[CDO] Hacking CDO to add an ability to search for commits affecting eObject or it's containments [message #1450341] |
Wed, 22 October 2014 10:47 |
Leonid Ripeynih Messages: 150 Registered: February 2012 |
Senior Member |
|
|
Hello all!
I'm about to start prototiping a new feature in CDO - an ability to search commits affecting given object or any of it's containments (recursively, of course).
So, that should give a user an ability to search for changes in 'files' (CDOResources) and 'folders' (CDOResourceFolders).
The implementation im (probably) capable of doing is DB (and, most probably, MEM) stores.
My proposed implementation (for DB store) is to add additional table
CDO_COMMIT_AFFECTED with the following columns:
COMMIT_TIME, CDO_ID, first referencing COMMIT_TIME from CDO_COMMIT_INFOS, other (referncing?) CDO_OBJECTS.
Then, on org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(OMMonitor) is should be possible to calculate a set of container cdo_objects from 'new' and 'changed' sets. (that should be log(n), which, seem reasonable).
Selecting the commits should also be fast, as it's just an idexed lookup to CDO_COMMIT_AFFECTED.CDO_ID, returning COMMIT_TIME's, and from there a standard cdo commit infos handlers should work.
I haven't yet designed CDO API/SPI/Implementation changes, but it seems that it should be doable.
Now, I want to sanity-check this feature (and implementation) idea. Is there anything wrong with this design? Can it be improved? Is there a workaround for this requirement?
|
|
|
Re: [CDO] Hacking CDO to add an ability to search for commits affecting eObject or it's containments [message #1451337 is a reply to message #1450341] |
Thu, 23 October 2014 17:26 |
|
Hi Leonid,
I think this could be a nice addition. If you consider to contribute it to CDO (and it sounds like it ;-) ) we need to
make sure that all the overhead (in space and time) that it creates is optional, i.e., the new functionality must be
configurable on the server side and probably discoverable on the client side (have a look at how other session
attributes are communicated to the client during the OpenSessionIndication/Confirmation protocol).
If you have questions regarding the architecture or the contribution process please let me know and I'll help you.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 22.10.2014 um 12:47 schrieb Leonid Ripeynih:
> Hello all!
>
> I'm about to start prototiping a new feature in CDO - an ability to search commits affecting given object or any of
> it's containments (recursively, of course).
>
> So, that should give a user an ability to search for changes in 'files' (CDOResources) and 'folders'
> (CDOResourceFolders).
>
> The implementation im (probably) capable of doing is DB (and, most probably, MEM) stores.
>
> My proposed implementation (for DB store) is to add additional table
> CDO_COMMIT_AFFECTED with the following columns: COMMIT_TIME, CDO_ID, first referencing COMMIT_TIME from
> CDO_COMMIT_INFOS, other (referncing?) CDO_OBJECTS.
> Then, on org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(OMMonitor) is should be possible to
> calculate a set of container cdo_objects from 'new' and 'changed' sets. (that should be log(n), which, seem reasonable).
>
> Selecting the commits should also be fast, as it's just an idexed lookup to CDO_COMMIT_AFFECTED.CDO_ID, returning
> COMMIT_TIME's, and from there a standard cdo commit infos handlers should work.
>
> I haven't yet designed CDO API/SPI/Implementation changes, but it seems that it should be doable.
>
> Now, I want to sanity-check this feature (and implementation) idea. Is there anything wrong with this design? Can it
> be improved? Is there a workaround for this requirement?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] Hacking CDO to add an ability to search for commits affecting eObject or it's containments [message #1451704 is a reply to message #1450341] |
Fri, 24 October 2014 07:01 |
Erdal Karaca Messages: 854 Registered: July 2009 |
Senior Member |
|
|
Doesn't this overlap with the auditing feature of CDO?
- query any object's history
- query the commit history and filter by object and traverse its containment tree
Leonid Ripeynih wrote on Wed, 22 October 2014 12:47Hello all!
I'm about to start prototiping a new feature in CDO - an ability to search commits affecting given object or any of it's containments (recursively, of course).
So, that should give a user an ability to search for changes in 'files' (CDOResources) and 'folders' (CDOResourceFolders).
The implementation im (probably) capable of doing is DB (and, most probably, MEM) stores.
My proposed implementation (for DB store) is to add additional table
CDO_COMMIT_AFFECTED with the following columns:
COMMIT_TIME, CDO_ID, first referencing COMMIT_TIME from CDO_COMMIT_INFOS, other (referncing?) CDO_OBJECTS.
Then, on org.eclipse.emf.cdo.internal.server.TransactionCommitContext.write(OMMonitor) is should be possible to calculate a set of container cdo_objects from 'new' and 'changed' sets. (that should be log(n), which, seem reasonable).
Selecting the commits should also be fast, as it's just an idexed lookup to CDO_COMMIT_AFFECTED.CDO_ID, returning COMMIT_TIME's, and from there a standard cdo commit infos handlers should work.
I haven't yet designed CDO API/SPI/Implementation changes, but it seems that it should be doable.
Now, I want to sanity-check this feature (and implementation) idea. Is there anything wrong with this design? Can it be improved? Is there a workaround for this requirement?
|
|
| | | | | |
Goto Forum:
Current Time: Mon Sep 23 14:10:34 GMT 2024
Powered by FUDForum. Page generated in 0.04171 seconds
|