Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMFStore] Updating product meta-model(Setting up a upgrade strategy for an EMFStore product including meta-model change)
| [EMFStore] Updating product meta-model [message #1442259] |
Fri, 10 October 2014 21:39  |
 Stephane Vaucher
Messages: 3
Registered: June 2011 |
Junior Member |
|
|
Hi everyone,
I'm interested in understanding how to use EMFStore and Edapt to support the upgrade of a product. We have a client base that uses a product of ours (an editor based on GMF/ECP/EMFStore). They currently synchronize their models via EMFStore. They have been using the product for a period of time, and soon we need to deliver a significant update that includes changes to the code, models and meta-models (we use a P2 repository to publish updates). The main question is: how can this be supported? I think Edapt is a good solution for meta-model evolution (I have used the code in a stand-alone manner and looked at the EMFMigrator code on git), but I don't know how this can fit into a product upgrade process as this does not seem to be possible without some code hacking. I might be naive, but I don't see my situation as a very uncommon use case. Some clarifications:
1. Clients typically work in a disconnected mode, so EMFStore will store the operations describing the current state of their models (until a commit is done). If a client wants to upgrade the product (and meta-model/models) as an arbitrary point in time, how can we support the fact that there might be uncommitted changes? The upgrade process should probably rely on Edapt to update their meta/models, but how can this migration be reconciled with the operations stored in EMFStore?
2. How can a server/client collaborate if they are at different versions of the meta-model? The simple answer would be to force an update (probably forced by the server), but if the client has uncommitted changes, he would probably be stuck (unless we have a solution for point 1).
3. If we are able to manage an update, would the migrated model lose its past versions?
I don't know if I'm missing anything obvious. I'm hoping that I might. Otherwise, I'd be interested in knowing how the bright people lurking on the forum might suggest as solutions.
Thanks,
Stephane Vaucher
|
|
|
| Re: [EMFStore] Updating product meta-model [message #1444463 is a reply to message #1442259] |
Tue, 14 October 2014 05:33  |
Jonas Helming
Messages: 699
Registered: July 2009 |
Senior Member |
|
|
Hi Stephane,
first of all, none of your questions sound naiv! :-)
About 1. and 2.: I would avoid this scenario of a "distributed
migration" at all costs. If the serer and the client have different
meta-models, changes cannot not be synchronized correctly, what happens,
if a certain attribute is only available on one side?
A simple solution would be: Ask all users to commit their changes at a
certain point in time. Update and migrate the server. Deploy the new
client. The new client could delete all local projects at first start-up
and force the user to re-checkout. Maybe the new client could check for
uncommitted changes before deleting the projects and at least save them
somehow, although it cannot be guaranteed that they can even be applied
anymore.
About number 3: It is also possible to migrate the history itself with
Edapt. If you want to keep it, it is even necessary to do so, otherwise
it would not be possible to switch back to old versions anymore. We have
supported projects in the past with this task.
Best regards
Jonas
Am 10.10.2014 23:39, schrieb Stephane Vaucher:
> Hi everyone,
>
> I'm interested in understanding how to use EMFStore and Edapt to support
> the upgrade of a product. We have a client base that uses a product of
> ours (an editor based on GMF/ECP/EMFStore). They currently synchronize
> their models via EMFStore. They have been using the product for a period
> of time, and soon we need to deliver a significant update that includes
> changes to the code, models and meta-models (we use a P2 repository to
> publish updates). The main question is: how can this be supported? I
> think Edapt is a good solution for meta-model evolution (I have used the
> code in a stand-alone manner and looked at the EMFMigrator code on git),
> but I don't know how this can fit into a product upgrade process as this
> does not seem to be possible without some code hacking. I might be
> naive, but I don't see my situation as a very uncommon use case. Some
> clarifications:
>
> 1. Clients typically work in a disconnected mode, so EMFStore will store
> the operations describing the current state of their models (until a
> commit is done). If a client wants to upgrade the product (and
> meta-model/models) as an arbitrary point in time, how can we support the
> fact that there might be uncommitted changes? The upgrade process should
> probably rely on Edapt to update their meta/models, but how can this
> migration be reconciled with the operations stored in EMFStore?
>
> 2. How can a server/client collaborate if they are at different versions
> of the meta-model? The simple answer would be to force an update
> (probably forced by the server), but if the client has uncommitted
> changes, he would probably be stuck (unless we have a solution for point
> 1).
>
> 3. If we are able to manage an update, would the migrated model lose its
> past versions?
>
> I don't know if I'm missing anything obvious. I'm hoping that I might.
> Otherwise, I'd be interested in knowing how the bright people lurking on
> the forum might suggest as solutions.
>
> Thanks,
> Stephane Vaucher
|
|
|
| Re: [EMFStore] Updating product meta-model [message #1444625 is a reply to message #1442259] |
Tue, 14 October 2014 10:25 |
Christophe Bouhier
Messages: 937
Registered: July 2009 |
Senior Member |
|
|
On 10-10-14 23:39, Stephane Vaucher wrote:
> Hi everyone,
>
> I'm interested in understanding how to use EMFStore and Edapt to support
> the upgrade of a product. We have a client base that uses a product of
> ours (an editor based on GMF/ECP/EMFStore). They currently synchronize
> their models via EMFStore. They have been using the product for a period
> of time, and soon we need to deliver a significant update that includes
> changes to the code, models and meta-models (we use a P2 repository to
> publish updates). The main question is: how can this be supported? I
> think Edapt is a good solution for meta-model evolution (I have used the
> code in a stand-alone manner and looked at the EMFMigrator code on git),
> but I don't know how this can fit into a product upgrade process as this
> does not seem to be possible without some code hacking. I might be
> naive, but I don't see my situation as a very uncommon use case. Some
> clarifications:
>
> 1. Clients typically work in a disconnected mode, so EMFStore will store
> the operations describing the current state of their models (until a
> commit is done). If a client wants to upgrade the product (and
> meta-model/models) as an arbitrary point in time, how can we support the
> fact that there might be uncommitted changes? The upgrade process should
> probably rely on Edapt to update their meta/models, but how can this
> migration be reconciled with the operations stored in EMFStore?
If you have a notification mechanims towards the client, you could
disable the client editing when out-of-sync with the upgraded metamodel
and model on the server. So the user would be forced to update (Run the
migration). You could run the migration by implementing a Migrator
extension on the client. (Which you could get via a p2 update).
So thinking out loud, it could look like this:
1. Client logs in. (Assuming some sort of authorization/authentication).
2. Client contacts server, server informs about a pending *mandatory*
migration.
3. User is asked to perform a p2 update to get the latest client code.
(With potential restart required).
4. Run the migrator when the user logs in (2nd time), as pending task
from the new P2 code.
5. Client contacts server again, informing upgrade took place.
It's not trivial....but with a pragmatic approach like checking a file
on disk after restart of the client, you could fetch a pending task and
block the UI from executing editing, to force the migration.
>
> 2. How can a server/client collaborate if they are at different versions
> of the meta-model? The simple answer would be to force an update
> (probably forced by the server), but if the client has uncommitted
> changes, he would probably be stuck (unless we have a solution for point
> 1).
just, do not allow editing, until the clients are migrated as well.
>
> 3. If we are able to manage an update, would the migrated model lose its
> past versions?
Edapt supports forward and backward migrations of model and metamodel.
>
> I don't know if I'm missing anything obvious. I'm hoping that I might.
> Otherwise, I'd be interested in knowing how the bright people lurking on
> the forum might suggest as solutions.
>
> Thanks,
> Stephane Vaucher
|
|
|
Goto Forum:
Current Time: Tue Apr 23 07:44:42 GMT 2024
Powered by FUDForum. Page generated in 0.02975 seconds |
] 
Search
Help
Register
Login
Home
