[Glass] Basic questions regarding GemBuilder for Smalltalk, GemTools, and tODE

[Johan Brichau]

> Thanks for the answer. We should really keep this thread stored somewhere! too many valuable information!

It's in the mailinglist archives, but you are right: we might want to make a consolidated page with all of this ;-)

> OK, here I am confused. Why would GLASS help me more than plain GemStone to run my app? I GUESS this is because Seaside itself needs some extensions to GemStone (for methods that do not exist there but do in Pharo) or something like that, hence our app has already covered several of these problems (those already present for Seaside and friends)? 

The Seaside implementation for Gemstone wraps every request in a transaction. In my view, this is essential to make your Seaside app behave exactly the way it would when you use image-based persistency in Pharo. There's other parts as well, but I found that an essential element to understand when moving our app to GLASS. 
Dale explains this way better than I do: http://gemstonesoup.wordpress.com/2007/05/07/transparent-persistence-for-seaside/

> So this is how you solve the fact that special select: and friends for indexes use a different syntax? because in my case, I would like the app to continue running in Pharo, so this: 
> 
> | aTime |
> aTime := Time now.
> myEmployees select: {:i | aTime == 
> i.name
> }
> 
> 
> will simply not work. Did you delegate to a strategy or Abstract Factory or similar, or is there a compatibility package for Pharo that can somehow understand and parse this?

Obviously, when you develop in Pharo, you want to be able to run your application there as well. That means you need to design the application so that you can localize differences related to what storage method you are using. From the very beginning, we made the architectural design choice to be able to run Yesplan on different databases. We decided to always go for object-oriented databases, but remain independent on which one that would be.

An abstract factory is indeed an essential pattern here, but so is a facade (put all those database query methods behind it).
it is essential to make the necessary abstractions and use object-oriented polymorhpism and class specialization to be able to deal with the required differences.
Most of the differences are related to optimizations though (indexes, reduced conflict collections, etc...).

We have a compatibility package too that contains methods we used in Pharo but that do not exist in Gemstone. 
Most of that we can actually contribute back to GLASS but it's rather limited anyway.

cheers
Johan