[Glass] Design API for adding/removing/editing objects in GemStone

[Dale K. Henrichs]

----- Original Message -----

| From: "Mariano Martinez Peck" <marianopeck at gmail.com>
| To: glass at lists.gemtalksystems.com
| Sent: Friday, November 15, 2013 7:41:04 AM
| Subject: [Glass] Design API for adding/removing/editing objects in
| GemStone

| Hi guys,

| First, let me say that I was really hoping that the User Guide has a
| chapter for what I will ask in this thread.

| Ok, I understood basic concepts of GemStone. I understood it's basic
| classes and libraries. I understood the basic transactions concepts.
| I could even run my webapp from inside GemStone. Cool. But now...
| how do I persist for real in GemStone? How do I design my app API
| for storing, retrieving, editing, removing objects?

| As far as I understand (please correct me if I am wrong), the first
| thing to know is that we should put our persistent objects somehow
| reachable from the user smalltalk dictionaries. Ok, as most OO DBs,
| GemStone works by reachability.
yes... 

| Second. Since the classes of my app are in those smalltalk
| dictionaries, and class variables are reachable from my classes,
| then whatever I store in class variables are persistent, right? (of
| course, unless I store there some objects that cannot be persisted).
yes... 

| Third...I would try not to enter too much in the transactions problem
| right now. I would like to keep using the GLASS as it comes for the
| moment...
Yes, I'm assuming that your application is a web app and the best/simplest way to manage transactions is to abort before the request is handled and commit before the response is returned ... This disadvantage of this approach (and the GemStone model in general) is that "long running operations" may span multiple http requests and you may end up needing to "rollback data that was previously commited". Johah has a Database Abstraction Layer project[1] that includes some support for these types of applications ... Johan has also presented at ESUG about this project, so slides are available as well ... 

With that said, it is prudent to keep things simple at the outset... 

[1] http://ss3.gemstone.com/ss/DALi.html 

| So...Ideas:

| 1) I keep a collection in a class side for each of my classes whose
| instances I want to persist. And I implement a protocol add: remove:
| etc that I put in Behavior. Them from my code I do: "Client
| addObject: anInstance"
Yes ... the only caveat is that you should consider whether the add objects messages may be sent from multiple concurrent requests .. if so, you should use one of the Rc* collection classes that are designed to minimize the likelihood of transaction conflicts ... 

Here are a couple of useful references[2][3] 

[2] http://gemstonesoup.wordpress.com/2007/12/16/gemstone-101-transaction-conflicts/ 
[3] http://gemstonesoup.wordpress.com/2010/02/11/gemstone-101-short-features/ 

| 2) I have one "MyAppRepository" class which is a singleton. The
| unique instance has a dictionary. From my code I do "MyAppRepository
| current addObject: anInstance".
| And MyAppRepository instance has a dict and operates for that dict
| (asking #class to the receiver and put that as keys...).
In GemStone I would avoid direct references to classes as much as possible (use names and a lookup instead). Classes in GemStone are versioned so it is very possible (and likely) that you will have multiple instances of a class floating around so it is not a good idea to hang onto them ... 

| 3) others...

| So, what do you do? My idea was to use 2) but reuse the repository
| class of Voyage and reuse also its protocol.

I don't think that you have to be fancy when dealing with persisting objects in GemStone ... I would recommend that you treat GemStone the same way you would treat the application in Pharo ... if it is natural to have a dictionary lookup by userid then store the dictionary along with the user class or in a a named global if that makes sense ... you don't have to have a central point of access as the entire Smalltalk object graph is persisted just like in Pharo ... if it is referenced it stays alive ... you can have a collection of users in one class variable and a collection of orders in another class variable and the orders can directly reference users without any need of worrying about identity or access paths or duplicate copies the object graph works just like smalltalk ... 

The one thing that you don't want to rely on is allInstances ... there is a tendency to rely on allInstances in client smalltalks to manage your objects and that is not a good practice in GemStone ... for large repositories, the allinstances operations can be very slow because of all of the disk i/o that will be involved ... so it makes sense to manage explicit collections of objects instead ... 

Dale 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131115/2e606b69/attachment.html>