Image-based persistence or something else?

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

Image-based persistence or something else?

William G. Davis
Hi.

I'm working on a project that's kind of text heavy.
The details aren't really important, but it's going to
have to store a decent amount of hypertext (perhaps as
much as 5-10 megs) somewhere.

Right now I have a class that stores objects for later
retrieval in several collections. The persistence is
achieved by making the class a Singleton; it stores an
instance of itself in a class variable and provides
access to the object with a class message (#instance).

Is this a bad system? Should I be using something
else? Will this cause too much of a headache when
upgrading Squeak or transferring data from one machine
to another?

Thanks.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

Reply | Threaded
Open this post in threaded view
|

Re: Image-based persistence or something else?

Diego Fernández

On 3/16/06, William G. Davis <[hidden email]> wrote:

Right now I have a class that stores objects for later
retrieval in several collections. The persistence is
achieved by making the class a Singleton; it stores an
instance of itself in a class variable and provides
access to the object with a class message (#instance).

Why not using a global to save the instance, instead of a "Singleton" with class variables?
This is unnecessary in St.
Singleton means "single-instance", but some people make a wrong use of this pattern to make well known instances --globals. Note that except for "null objects", is very difficult to known if class represents something unique, so singletons are usually used only for performance reasons.
 

Is this a bad system? Should I be using something
else?

Except for the singletons it's not bad :), you can design your system in that way and then add other persistence mechanisms when necessary.  

Will this cause too much of a headache when
upgrading Squeak or transferring data from one machine
to another?


Yes :(
Squeak image is not designed as a multi-user, transactional image so using the image in that way can be a headache when your application grows.

Maybe you can use some OODB to solve this problem, (the most used OODB is GemStone, that is a St prepared for persistence: an image with multi-user and transaction support, is very powerful but is very expensive for a small project :(, take a look at: http://www.gemstone.com/ and http://minnow.cc.gatech.edu/squeak/1957 )

There are some free OODB frameworks for Squeak:
MinneStore: http://minnestore.sourceforge.net/index.html
Magma: http://minnow.cc.gatech.edu/squeak/2665





Reply | Threaded
Open this post in threaded view
|

Re: Image-based persistence or something else?

Lord ZealoN
> Squeak image is not designed as a multi-user, transactional image so using the
> image in that way can be a headache when your application grows.
 
I was thinking thath squeak is developed especially about this.

 
2006/3/17, Diego Fernandez <[hidden email]>:

On 3/16/06, William G. Davis <[hidden email]> wrote:

Right now I have a class that stores objects for later
retrieval in several collections. The persistence is
achieved by making the class a Singleton; it stores an
instance of itself in a class variable and provides
access to the object with a class message (#instance).

Why not using a global to save the instance, instead of a "Singleton" with class variables?
This is unnecessary in St.
Singleton means "single-instance", but some people make a wrong use of this pattern to make well known instances --globals. Note that except for "null objects", is very difficult to known if class represents something unique, so singletons are usually used only for performance reasons.
 

Is this a bad system? Should I be using something
else?

Except for the singletons it's not bad :), you can design your system in that way and then add other persistence mechanisms when necessary.  

Will this cause too much of a headache when
upgrading Squeak or transferring data from one machine
to another?


Yes :(
Squeak image is not designed as a multi-user, transactional image so using the image in that way can be a headache when your application grows.

Maybe you can use some OODB to solve this problem, (the most used OODB is GemStone, that is a St prepared for persistence: an image with multi-user and transaction support, is very powerful but is very expensive for a small project :(, take a look at: <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.gemstone.com/" target="_blank">http://www.gemstone.com/ and <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://minnow.cc.gatech.edu/squeak/1957" target="_blank"> http://minnow.cc.gatech.edu/squeak/1957 )

There are some free OODB frameworks for Squeak:
MinneStore: <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://minnestore.sourceforge.net/index.html" target="_blank"> http://minnestore.sourceforge.net/index.html
Magma: <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://minnow.cc.gatech.edu/squeak/2665" target="_blank">http://minnow.cc.gatech.edu/squeak/2665










Reply | Threaded
Open this post in threaded view
|

Re: Image-based persistence or something else?

Markus Gälli-3
In reply to this post by Diego Fernández

On Mar 17, 2006, at 6:14 AM, Diego Fernandez wrote:

> Why not using a global to save the instance, instead of a  
> "Singleton" with class variables?
> This is unnecessary in St.

I don't agree because
- Singletons make the usage of global variables more cumbersome, thus  
hopefully more rare.
- Singletons are a - still too - widespread pattern now, developers  
expect them more than pure globals. Don't surprise your readers...

In my opinion a well designed system only has one root but lot of  
context.
Each context should be as big as necessary but as narrow as possible.
As soon as you need to introduce a second singleton into your  
application - think twice.

Cheers,

Markus