27 Jun
2008
27 Jun
'08
6:57 p.m.
let us imagine that we would like to see what would happen if we would
move
a class A from package P1 to P2, without changing the source code and
may be been able to undo the change
Solution A:
We could copy the complete model, modify it. (and keep somewhere an
history)
Solution B:
We could change the model and keep an history of the changes (move A
P1 P2).
Solution C: I could cache in each model a timestamp similar to what
frederic pluquet did
and know at which version modification we are. then for a given
changes I could get the model by getting entity at the same level or
lower.
Any thoughts on that.
I have the impression that solution B is easier.
stef
27 Jun
27 Jun
11:54 p.m.
I would suggest to use Hismo :).
The default behavior for Hismo is Solution A, because typically we
have the versions and we need to extract histories. That is why we
have duplicated models.
But, for example in the case of YellowSubmarine - the SVN client, we
do not duplicate that information. The trick there was to not use the
default EntityVersion which requires a corresponding entity for each
version. Instead, he subclassed AbstractVersion to just hold the diff
and then recompute the content of the entity.
However, you also have to consider what the end goal is. If you want
to perform computations on each version, you might end up needing both
complete models. In this case, it probably is easier to just go for
Solution A.
Doru
On Jun 27, 2008, at 6:57 PM, Stéphane Ducasse wrote:
let us imagine that we would like to see what would
happen if we would
move
a class A from package P1 to P2, without changing the source code and
may be been able to undo the change
Solution A:
We could copy the complete model, modify it. (and keep somewhere an
history)
Solution B:
We could change the model and keep an history of the changes (move A
P1 P2).
Solution C: I could cache in each model a timestamp similar to what
frederic pluquet did
and know at which version modification we are. then for a given
changes I could get the model by getting entity at the same level or
lower.
Any thoughts on that.
I have the impression that solution B is easier.
stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Obvious things are difficult to teach."
28 Jun
28 Jun
7:52 a.m.
indeed I do not really know.
I think that we will go for version B in our case
stef
On Jun 27, 2008, at 11:54 PM, Tudor Girba wrote:
I would suggest to use Hismo :).
The default behavior for Hismo is Solution A, because typically we
have the versions and we need to extract histories. That is why we
have duplicated models.
But, for example in the case of YellowSubmarine - the SVN client, we
do not duplicate that information. The trick there was to not use the
default EntityVersion which requires a corresponding entity for each
version. Instead, he subclassed AbstractVersion to just hold the diff
and then recompute the content of the entity.
However, you also have to consider what the end goal is. If you want
to perform computations on each version, you might end up needing both
complete models. In this case, it probably is easier to just go for
Solution A.
Doru
On Jun 27, 2008, at 6:57 PM, Stéphane Ducasse wrote:
let us imagine that we would like to see what
would happen if we
would
move
a class A from package P1 to P2, without changing the source code and
may be been able to undo the change
Solution A:
We could copy the complete model, modify it. (and keep somewhere an
history)
Solution B:
We could change the model and keep an history of the changes (move A
P1 P2).
Solution C: I could cache in each model a timestamp similar to what
frederic pluquet did
and know at which version modification we are. then for a given
changes I could get the model by getting entity at the same level or
lower.
Any thoughts on that.
I have the impression that solution B is easier.
stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
17 Jul
17 Jul
3:06 p.m.
Actually I do the solution B but I do not use any thing for changes
history (for the moment I do not need the changes history).
Doru, When you say that the default behavior for Hismo is Solution A
you wont to say that in hismo we can do something like this:
aMooseModel deepCopy
and the result is a new model identical to aMooseModel but without
any pointer to any entity into aMooseModel?
hani
On 28 juin 08, at 07:52, Stéphane Ducasse wrote:
indeed I do not really know.
I think that we will go for version B in our case
stef
On Jun 27, 2008, at 11:54 PM, Tudor Girba wrote:
I would suggest to use Hismo :).
The default behavior for Hismo is Solution A, because typically we
have the versions and we need to extract histories. That is why we
have duplicated models.
But, for example in the case of YellowSubmarine - the SVN client, we
do not duplicate that information. The trick there was to not use the
default EntityVersion which requires a corresponding entity for each
version. Instead, he subclassed AbstractVersion to just hold the diff
and then recompute the content of the entity.
However, you also have to consider what the end goal is. If you want
to perform computations on each version, you might end up needing
both
complete models. In this case, it probably is easier to just go for
Solution A.
Doru
On Jun 27, 2008, at 6:57 PM, Stéphane Ducasse wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
let us imagine that we would like to see what
would happen if we
would
move
a class A from package P1 to P2, without changing the source code
and
may be been able to undo the change
Solution A:
We could copy the complete model, modify it. (and keep somewhere an
history)
Solution B:
We could change the model and keep an history of the changes
(move A
P1 P2).
Solution C: I could cache in each model a timestamp similar to what
frederic pluquet did
and know at which version modification we are. then for a given
changes I could get the model by getting entity at the same level or
lower.
Any thoughts on that.
I have the impression that solution B is easier.
stef
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5927
days inactive
5947
days old
3 comments
4 participants
participants (4)
-
Stéphane Ducasse -
Stéphane Ducasse -
Tudor Girba -
Univ-SAVOIE