[BUG ? Feature ?] Store redundancy #2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[BUG ? Feature ?] Store redundancy #2

Mark Pirogovsky-3
Hello all,

I think I did ask similar question about a month ago - did not get any
answers though.

Here is the Store inefficiency again.

I have a long lived package in the application.  Somewhere somehow, one
of the developers did remove a method thinking it was obsolete.  It
turned out his decision was incorrect.

I need to restore the method (originally published 3 years ago !). I am
finding the method in the repository  and tell the store  to load it.
So far so good.  Then I do commit the package.  To my surprise, that
retarded STORE, creates a new version of that old method again.  So I
now have two implementation of the same identical method in the
repository - original 3 years old and brand new.

You probably would say - "one method -- what is a big deal, space is
cheap...".  It is not a big deal for me as I know what has happened.
But for other members of the development group, or new person, it will
be a big deal as they would have to understand why do we have multiple
version of the same method or maybe they are not identical, etc...


Thanks everybody,

--Mark



Reply | Threaded
Open this post in threaded view
|

Re: [BUG ? Feature ?] Store redundancy #2

Alan Knight-2
When you apply a method into the image, Store does not remember the database information about that method, it just loads it into Smalltalk. So the only way it knows to reuse a database record is if that record was also used by the parent of the version you are publishing.

At 04:00 PM 7/10/2006, Mark Pirogovsky wrote:

>Hello all,
>
>I think I did ask similar question about a month ago - did not get any answers though.
>
>Here is the Store inefficiency again.
>
>I have a long lived package in the application.  Somewhere somehow, one of the developers did remove a method thinking it was obsolete.  It turned out his decision was incorrect.
>
>I need to restore the method (originally published 3 years ago !). I am finding the method in the repository  and tell the store  to load it. So far so good.  Then I do commit the package.  To my surprise, that retarded STORE, creates a new version of that old method again.  So I now have two implementation of the same identical method in the repository - original 3 years old and brand new.
>
>You probably would say - "one method -- what is a big deal, space is cheap...".  It is not a big deal for me as I know what has happened. But for other members of the development group, or new person, it will be a big deal as they would have to understand why do we have multiple version of the same method or maybe they are not identical, etc...
>
>
>Thanks everybody,
>
>--Mark
>
>

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Reply | Threaded
Open this post in threaded view
|

Re: [BUG ? Feature ?] Store redundancy #2

Mark Pirogovsky-3
Alan,
Thanks for the reply.

It appears that Store not only forgets about the "database information"
for methods but also for the classes, and global.  I already asked the
questions about this awhile ago.


So, is it possible to share the SAME VERSION of the CLASS(with or
without methods) in two different unrelated packages ?

Any info is greatly appreciated.

--Mark

P.S.  I may vaguely recall similar discussions somewhere about 4 years
ago, but can not find details of it. If I remember correctly the idea
was to have a class per package :-(

Alan Knight wrote:

> When you apply a method into the image, Store does not remember the database information about that method, it just loads it into Smalltalk. So the only way it knows to reuse a database record is if that record was also used by the parent of the version you are publishing.
>
> At 04:00 PM 7/10/2006, Mark Pirogovsky wrote:
>
>>Hello all,
>>
>>I think I did ask similar question about a month ago - did not get any answers though.
>>
>>Here is the Store inefficiency again.
>>
>>I have a long lived package in the application.  Somewhere somehow, one of the developers did remove a method thinking it was obsolete.  It turned out his decision was incorrect.
>>
>>I need to restore the method (originally published 3 years ago !). I am finding the method in the repository  and tell the store  to load it. So far so good.  Then I do commit the package.  To my surprise, that retarded STORE, creates a new version of that old method again.  So I now have two implementation of the same identical method in the repository - original 3 years old and brand new.
>>
>>You probably would say - "one method -- what is a big deal, space is cheap...".  It is not a big deal for me as I know what has happened. But for other members of the development group, or new person, it will be a big deal as they would have to understand why do we have multiple version of the same method or maybe they are not identical, etc...
>>
>>
>>Thanks everybody,
>>
>>--Mark
>>
>>
>
>
> --
> Alan Knight [|], Cincom Smalltalk Development
> [hidden email]
> [hidden email]
> http://www.cincom.com/smalltalk
>
> "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [BUG ? Feature ?] Store redundancy #2

Alan Knight-2
Yes, it treats everything the same way.

No, I don't think it would be possible to share the same database version of the class definition in two different packages. At least not without considerable modification. Store doesn't really have the notion of a class, just of a definition and of methods and shared variables.

At 01:24 PM 7/17/2006, Mark Pirogovsky wrote:

>Alan,
>Thanks for the reply.
>
>It appears that Store not only forgets about the "database information" for methods but also for the classes, and global.  I already asked the questions about this awhile ago.
>
>
>So, is it possible to share the SAME VERSION of the CLASS(with or without methods) in two different unrelated packages ?
>
>Any info is greatly appreciated.
>
>--Mark
>
>P.S.  I may vaguely recall similar discussions somewhere about 4 years ago, but can not find details of it. If I remember correctly the idea was to have a class per package :-(
>
>Alan Knight wrote:
>>When you apply a method into the image, Store does not remember the database information about that method, it just loads it into Smalltalk. So the only way it knows to reuse a database record is if that record was also used by the parent of the version you are publishing.
>>At 04:00 PM 7/10/2006, Mark Pirogovsky wrote:
>>
>>>Hello all,
>>>
>>>I think I did ask similar question about a month ago - did not get any answers though.
>>>
>>>Here is the Store inefficiency again.
>>>
>>>I have a long lived package in the application.  Somewhere somehow, one of the developers did remove a method thinking it was obsolete.  It turned out his decision was incorrect.
>>>
>>>I need to restore the method (originally published 3 years ago !). I am finding the method in the repository  and tell the store  to load it. So far so good.  Then I do commit the package.  To my surprise, that retarded STORE, creates a new version of that old method again.  So I now have two implementation of the same identical method in the repository - original 3 years old and brand new.
>>>
>>>You probably would say - "one method -- what is a big deal, space is cheap...".  It is not a big deal for me as I know what has happened. But for other members of the development group, or new person, it will be a big deal as they would have to understand why do we have multiple version of the same method or maybe they are not identical, etc...
>>>
>>>
>>>Thanks everybody,
>>>
>>>--Mark
>>>
>>
>>--
>>Alan Knight [|], Cincom Smalltalk Development
>>[hidden email]
>>[hidden email]
>>http://www.cincom.com/smalltalk
>>"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross
>>

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross