Home » Modeling » EMF » [CDO] disable revisions(delete old revisions automatically)
| | | | | | | | | | | | |
Re: [CDO] disable revisions [message #988367 is a reply to message #691395] |
Thu, 29 November 2012 15:59 |
Silvestre Martins Messages: 84 Registered: July 2009 |
Member |
|
|
I have a question related with the support of auditing mode.
Scenario:
Imagine we need to perform a read-only and very time consuming operation. Therefore is can be done in a separate and concurrent procedure. No need to take care about conflicts at the end because is read-only.
This operation must be done in a "snapshot" of the model (such that all reads must look to the same state of a given moment, here the moment when the operation started).
With CDO, this seems to fit very well the feature of Auditing.
The problem is that this requires the database stores all revisions, regardless if we will need to audit it or not, which leads to database growing very fast.
My question is: could we have a mechanism of deleting an old revision?
Or even better, could we, instead of having constantly new revisions being created every time a row is changed, do it only when a specific state was marked to be kept. We could assign a special identifier to these rows, every time the row is changed, and then it would be easy to just remove the old rows.
Is this somehow already possible in CDO?
|
|
|
Re: [CDO] disable revisions [message #988395 is a reply to message #988367] |
Thu, 29 November 2012 17:35 |
|
Am 29.11.2012 16:59, schrieb Silvestre Martins:
> I have a question related with the support of auditing mode.
>
> Scenario:
> Imagine we need to perform a read-only and very time consuming operation. Therefore is can be done in a separate and
> concurrent procedure. No need to take care about conflicts at the end because is read-only.
> This operation must be done in a "snapshot" of the model (such that all reads must look to the same state of a given
> moment, here the moment when the operation started).
>
> With CDO, this seems to fit very well the feature of Auditing.
> The problem is that this requires the database stores all revisions, regardless if we will need to audit it or not,
> which leads to database growing very fast.
>
> My question is: could we have a mechanism of deleting an old revision?
>
> Or even better, could we, instead of having constantly new revisions being created every time a row is changed, do it
> only when a specific state was marked to be kept. We could assign a special identifier to these rows, every time the
> row is changed, and then it would be easy to just remove the old rows.
>
> Is this somehow already possible in CDO?
No, not yet. It sounds interesting, though. Are you volunteering to develop such functionality?
BTW. I don't think we should "associate" something (like a " special identifier") with rows explicitely. A collection of
timestamps should do, too. And I wonder if all this must impact the storage layer at all. What about just changing the
server-side revision cache?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] disable revisions [message #988404 is a reply to message #988395] |
Thu, 29 November 2012 18:53 |
Silvestre Martins Messages: 84 Registered: July 2009 |
Member |
|
|
Eike Stepper wrote on Thu, 29 November 2012 12:35Am 29.11.2012 16:59, schrieb Silvestre Martins:
> I have a question related with the support of auditing mode.
>
> Scenario:
> Imagine we need to perform a read-only and very time consuming operation. Therefore is can be done in a separate and
> concurrent procedure. No need to take care about conflicts at the end because is read-only.
> This operation must be done in a "snapshot" of the model (such that all reads must look to the same state of a given
> moment, here the moment when the operation started).
>
> With CDO, this seems to fit very well the feature of Auditing.
> The problem is that this requires the database stores all revisions, regardless if we will need to audit it or not,
> which leads to database growing very fast.
>
> My question is: could we have a mechanism of deleting an old revision?
>
> Or even better, could we, instead of having constantly new revisions being created every time a row is changed, do it
> only when a specific state was marked to be kept. We could assign a special identifier to these rows, every time the
> row is changed, and then it would be easy to just remove the old rows.
>
> Is this somehow already possible in CDO?
No, not yet. It sounds interesting, though. Are you volunteering to develop such functionality?
Not really, currently I'm still evaluating if we can adopt CDO in our project. Of course the possibility and how easy is to implement such features (internally or not) will also influence the decision.
Quote:
BTW. I don't think we should "associate" something (like a " special identifier") with rows explicitely. A collection of
timestamps should do, too. And I wonder if all this must impact the storage layer at all. What about just changing the
server-side revision cache?
I don't know the details of implementation of CDO, but I suppose that to support "partial" auditing (i.e., creates different version only when the current version was marked to be kept) would depend on the storage layer.
Anyway, you are right, applying a marker is not efficient, because you would need to update all tables. It would be easier to just create a special table to store "durable views", that would only need an ID and a timestamp.
Then, when deciding if we make an update on the row, or instead insert a new row, we would query this table. If there is an entry in "durable views" with timestamp equal or higher than the timestamp of the existing row being updated, then make an insert and keep existing row.
When removing this "durable view", we just need to remove the entry from this table, plus all rows in all tables where the timestamp is equal or lower than the timestamp of the "durable view" and a newer version of that line exists. As sooner the "durable view" is removed, as sooner we would stop to create new rows instead of update them.
Sounds easy, I just don't if this is more efficient that just enabling the Auditing
[Updated on: Thu, 29 November 2012 18:59] Report message to a moderator
|
|
|
Re: [CDO] disable revisions [message #988406 is a reply to message #988404] |
Thu, 29 November 2012 19:02 |
|
Am 29.11.2012 19:53, schrieb Silvestre Martins:
> Quote:
>> BTW. I don't think we should "associate" something (like a " special identifier") with rows explicitely. A collection
>> of timestamps should do, too. And I wonder if all this must impact the storage layer at all. What about just changing
>> the server-side revision cache?
>
> I don't know the details of implementation of CDO, but I suppose that to support "partial" auditing (i.e., creates
> different version only when the current version was marked to be kept) would depend on the storage layer.
The term "partial auditing" is already reserved for the more horizontal aspect of supporting auditiing only for a subset
of the model classes. It's not supported by CDO, yet.
>
> Anyway, you are right, applying a marker is not efficient, because you would need to update all tables. It would be
> easier to just create a special table to store "durable views", that would only need an ID and a timestamp. Then, when
> deciding if we make an update on the row, or instead insert a new row, we would query this table. If there is an entry
> in "durable views" with timestamp equal or higher than the timestamp of the existing row being updated, then make an
> insert and keep existing row.
> When removing this "durable view", we just need to remove the entry from this table, plus all rows in all tables where
> the timestamp is equal or lower than the timestamp of the "durable view" and a newer version of that line exists. As
> sooner the "durable view" is removed, as sooner we would stop to create new rows instead of update them.
> Sounds easy, I just don't if this is more efficient that just enabling the Auditing :)
Let's discuss the details then when it's clear that someone will actually implement it ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] disable revisions [message #988407 is a reply to message #988406] |
Thu, 29 November 2012 19:09 |
Silvestre Martins Messages: 84 Registered: July 2009 |
Member |
|
|
Eike Stepper wrote on Thu, 29 November 2012 14:02Am 29.11.2012 19:53, schrieb Silvestre Martins:
> Quote:
>> BTW. I don't think we should "associate" something (like a " special identifier") with rows explicitely. A collection
>> of timestamps should do, too. And I wonder if all this must impact the storage layer at all. What about just changing
>> the server-side revision cache?
>
> I don't know the details of implementation of CDO, but I suppose that to support "partial" auditing (i.e., creates
> different version only when the current version was marked to be kept) would depend on the storage layer.
The term "partial auditing" is already reserved for the more horizontal aspect of supporting auditiing only for a subset
of the model classes. It's not supported by CDO, yet.
>
> Anyway, you are right, applying a marker is not efficient, because you would need to update all tables. It would be
> easier to just create a special table to store "durable views", that would only need an ID and a timestamp. Then, when
> deciding if we make an update on the row, or instead insert a new row, we would query this table. If there is an entry
> in "durable views" with timestamp equal or higher than the timestamp of the existing row being updated, then make an
> insert and keep existing row.
> When removing this "durable view", we just need to remove the entry from this table, plus all rows in all tables where
> the timestamp is equal or lower than the timestamp of the "durable view" and a newer version of that line exists. As
> sooner the "durable view" is removed, as sooner we would stop to create new rows instead of update them.
> Sounds easy, I just don't if this is more efficient that just enabling the Auditing
Let's discuss the details then when it's clear that someone will actually implement it
Yes, sure. I was just trying to figure out how complex or simple this could be.
Cheers,
Silvestre
|
|
|
Goto Forum:
Current Time: Tue Sep 24 13:48:25 GMT 2024
Powered by FUDForum. Page generated in 0.05008 seconds
|