Newbie from Glorp Question

Hi all... I just got my GS/SS installation up (thanks to Sean!) and running and am starting to poke around and learn this stuff.

I want to make sure what I am seeing...

the scenario is...

I make some changes, get to another screen for review and can then
either save those changes
or roll them back to the previous state?

On Tue, Apr 27, 2010 at 8:17 AM, Chris Curtis <[hidden email]> wrote:

Sort of ... it's slightly more interactive than that. Here's a more complete fragment of the code:

So until save is hit, you dont update anything.

So taking GLORP to Gemstone.

Your sql database with glorp is your persistent store ala Gemstone OODB.
Save moves the data to the persistent store. With Gemstone, anything that is
reachable from a persistent root is persisted so.

With sql, you create a smalltak object for a user, this is an
intermediate representation
of a 'persistent user' in your sql database. Do the same thing with gemstone,
create a non persistent user to make modifications to and then on save,
update the persistent user, on cancel, return to the original state.

So when you hand off a user to your Seaside component, don't give it
the persistent user,
give it a copy of the persistent user that isnt reachable ( or give it
a persistent user
and then copy it behind the scenes ). When they save, sync the persistent user
with the temporary one and then let the temp instance get garbage collected.

On Tue, Apr 27, 2010 at 8:54 AM, Chris Curtis <[hidden email]> wrote:

One more thought I had after the fact,

a copy might get messy, Creating a new temporary user from an existing
one might work better
if your object has a deep graph of complicated objects.

On Tue, Apr 27, 2010 at 9:02 AM, Sean Allen <[hidden email]> wrote:

Chris,

Welcome to GemStone. Sean has given you some good advice, and I'll throw in my comments.

First, I'd suggest you take a look at my Seaside tutorial (http://seaside.gemstone.com/tutorial). Given that you are already familiar with Seaside, the relevant part would be Chapter 11 on forms.

Basically, Seaside supports the HTML concept of buttons for submit, cancel, and reset. When a user clicks the submit button, then all the entry fields on the form have their callbacks evaluated before the submit button's callback. When a user clicks the cancel button, none of the entry fields have their callbacks evaluated. Thus, the simplest model is that each entry field updates the model and the submit button ensures that the model is part of a persistent collection:

        html textInput callback: [:value | model name: value]; with: model value.
        html submitButton callback: [self persistentIdentitySetOfModels add: model. self answer model]; with: 'Save'. "commit is automatic"
        html cancelButton callback: [self answer: nil]; with: 'Cancel'. "Input callbacks will not have run, so no need for rollback"

This is a simple approach. Things can get more complex from here...

James

On Apr 27, 2010, at 5:17 AM, Chris Curtis wrote:

One thing I have found and others will probably disagree( and some
might agree ) but I strongly suggest not storing your data in class
variables on
objects. Create a graph like this:

MySystem <-- global variable, gets persisted
   UserSystem

then store your users in an instance variable of user system.

It will allow you to run multiple versions of your application if
needed in the same code by just letting it know which system to use.

On Tue, Apr 27, 2010 at 11:08 AM, James Foster
<[hidden email]> wrote:

While we've typically suggested class (instance) variables as a first approach for persistence, Sean's suggestion is excellent. And, not just for the reason he mentions, but also because GemStone historically has not migrated class (instance) variables when you create a new version of the class, so the instances can seem to disappear.

James

On Apr 27, 2010, at 8:31 AM, Sean Allen wrote:

Thanks for the pointers!

Chris,

As you note, creating a transient version of a model by using some variation of #'copy' is highly dependent on "how the graph is used." I find that approach somewhat complex and have managed to avoid it so far. If you can't rely on having the callbacks run only on form submit and find that something more sophisticated is needed, then I'd suggest adding instance variables to your subclass of WAComponent and keeping intermediate data there (based on widget-specific callbacks) and then updating the model in the submit callback.

As to where to put the graph root, you have a decent start in your sample RootTask class>>#'initialize' method, but I'd suggest another approach. Create a top-level domain model class with a name ending in 'System' (e.g., VideoStoreSystem), and on its class-side have an accessor, #'default' or #'current', that does lazy initialization:

VideoStoreSystem class>>#'current'
        ^(System myUserProfile objectNamed: #'UserGlobals')
                at: #'VideoStoreSystem_Current'
                ifAbsentPut: [self new].

At this point, you send messages to the instance of VideoStoreSystem, like #'users' or #'userWithID:' or #'addUser:'. The general idea is that using a Dictionary to hold objects is not as nice as creating a new class to encapsulate your domain. Now, if you want to run tests, you copy the global to another place, install a test system, run the tests, then revert the main system.

As to the tutorial, you should be able to use the GLASS license for GemStone Seaside work.

James

On Apr 27, 2010, at 6:42 PM, Chris Curtis wrote:

On Apr 27, 2010, at 9:38 AM, James Foster wrote:

> While we've typically suggested class (instance) variables as a first approach for persistence, Sean's suggestion is excellent.

True.

> And, not just for the reason he mentions, but also because GemStone historically has not migrated class (instance) variables when you create a new version of the class, so the instances can seem to disappear.

But since GLASS has migrated class (instance) variables this historic problem is fixed so the reason is moot and probably should not have been mentioned since it adds more confusion than clarification...

James

Today I would say that James and I are leaning toward storing globals separately from the class for a couple of different reasons:

  - using class (instance) vars makes it difficult to share code amongst multiple
    GemStone users (ala DataCurator and SystemUser)
  - upgrade/migration customization easier when avoiding class (instace vars)

In GemStone it is possible to create multiple users at the data base level which allows one to have multiple independent instances of Seaside or Pier running in the same stone. In fact, with appropriate segments and permissions it is possible to completely isolate the independent instances from each other....Furthermore with the GemStone namespace model it is possible to share the common code as well, except if you use class (instance) vars.

As far as upgrade/migration goes, suffice to say that being able to remove a class completely from the system without losing data (i.e.,  not relying upon class (instance) vars for persistence) is useful in certain circumstances.

In the end, we are starting the think that Sean's suggestion is a good one...

Dale

----- "James Foster" <[hidden email]> wrote:

| While we've typically suggested class (instance) variables as a first
| approach for persistence, Sean's suggestion is excellent. And, not
| just for the reason he mentions, but also because GemStone
| historically has not migrated class (instance) variables when you
| create a new version of the class, so the instances can seem to
| disappear.
|
| James
|
| On Apr 27, 2010, at 8:31 AM, Sean Allen wrote:
|
| > One thing I have found and others will probably disagree( and some
| > might agree ) but I strongly suggest not storing your data in class
| > variables on
| > objects. Create a graph like this:
| >
| > MySystem <-- global variable, gets persisted
| >   UserSystem
| >
| > then store your users in an instance variable of user system.
| >
| > It will allow you to run multiple versions of your application if
| > needed in the same code by just letting it know which system to
| use.
| >
| > On Tue, Apr 27, 2010 at 11:08 AM, James Foster
| > <[hidden email]> wrote:
| >> Chris,
| >>
| >> Welcome to GemStone. Sean has given you some good advice, and I'll
| throw in my comments.
| >>
| >> First, I'd suggest you take a look at my Seaside tutorial
| (http://seaside.gemstone.com/tutorial). Given that you are already
| familiar with Seaside, the relevant part would be Chapter 11 on
| forms.
| >>
| >> Basically, Seaside supports the HTML concept of buttons for submit,
| cancel, and reset. When a user clicks the submit button, then all the
| entry fields on the form have their callbacks evaluated before the
| submit button's callback. When a user clicks the cancel button, none
| of the entry fields have their callbacks evaluated. Thus, the simplest
| model is that each entry field updates the model and the submit button
| ensures that the model is part of a persistent collection:
| >>
| >>        html textInput callback: [:value | model name: value]; with:
| model value.
| >>        html submitButton callback: [self
| persistentIdentitySetOfModels add: model. self answer model]; with:
| 'Save'.           "commit is automatic"
| >>        html cancelButton callback: [self answer: nil]; with:
| 'Cancel'. "Input callbacks will not have run, so no need for
| rollback"
| >>
| >> This is a simple approach. Things can get more complex from
| here...
| >>
| >> James
| >>
| >> On Apr 27, 2010, at 5:17 AM, Chris Curtis wrote:
| >>
| >>> Hi all... I just got my GS/SS installation up (thanks to Sean!)
| and running and am starting to poke around and learn this stuff.
| >>>
| >>> My first big question is what the 'correct' persistence pattern
| is. I've read elsewhere that the GS implementation of Seaside does a
| commit every request to simplify the transaction handling, and I'm
| wondering how I should map that over from my existing code.
| >>>
| >>> For example, I'm used to something like this using Glorp:
| >>>
| >>>     html button callback: [ user bePersistent; commitUnitOfWork.
| self answer: user ]; with: 'Save'.
| >>>     html button callback: [ user rollbackUnitOfWork. self answer:
| nil ]; with: 'Cancel'.
| >>>
| >>> Leaving aside whether that's actually correct usage for Glorp, how
| should I be doing that in GemStone?
| >>>
| >>> --chris
| >>
| >>

On Thu, Apr 29, 2010 at 3:18 PM, Dale Henrichs <[hidden email]> wrote:

Chris,

Hi,

On 27.04.2010, at 14:17, Chris Curtis wrote:
I'm late in the thread. There were quite a few very good response. As I don't know where to reply I just do it to the first message. I don't know if I can add some valuable but I want to share my experience on this.

I started to use class vars for holding instances a while ago. It bit me every single time I upgraded something. Knowing that you just need to copy your instances from an old class version makes it easier but the overall setup becomes error prone. The same goes for using a class as key somewhere. Back then I also tried something like

UserGlobals at: MyClass

This does not work either. After an upgrade the class MyClass is just different from the class when you used it as a key. Sorry but true these are two rules for me to make my life easier: avoid using class vars for persistent data and don't use classes directly as key anywhere.

As I am a lazy person I changed the setup to work more generic than to care for every single domain class in *System approach.

Now I use this approach (which is nearly the same as you advized).

HRModel class>>default
        ^ default ifNil: [ default := HRModel new ]

HRModel class>>instancesOf: aClass
        ^ self default instancesOf: aClass

HRModel>>root
        ^ root ifNil: [ root := IdentityDictionary new ]

HRModel>>at: aString
        ^ self root at: aString ifAbsentPut: [ OrderedCollection new ]

HRModel>>instancesOf: aClass
        ^ self at: aClass name

Then in the base class or any class of my model I add

HRSomeThing class>>instances
        ^ HRModel instancesOf: self
                       
This way I avoid using class vars and the classes are resolved by name. Works out pretty well so far.

For the other topic about providing safe cancel operations I like to put Magritte in the mix. It does exactly this. It handles mementos of your object model as long as you are working on it. The memento itself has a save and cancel operation to write the content back to the object or throw it away. From a gemstone point of view where everything is written as soon as it has been changed it is the perfect match. Well, it is another piece of not-so-lightweight software but I think it is worth it.

Norbert

> I'm late in the thread. There were quite a few very good response. As I don't know where to reply I just do it to the first message. I don't know if I can add some valuable but I want to share my experience on this.
>
> I started to use class vars for holding instances a while ago. It bit me every single time I upgraded something. Knowing that you just need to copy your instances from an old class version makes it easier but the overall setup becomes error prone. The same goes for using a class as key somewhere. Back then I also tried something like
>
> UserGlobals at: MyClass
>
> This does not work either. After an upgrade the class MyClass is just different from the class when you used it as a key. Sorry but true these are two rules for me to make my life easier: avoid using class vars for persistent data and don't use classes directly as key anywhere.

I second this. Use a symbol and lookup the class from the symbol.
We have to go back through our code and fix this. We have several
places where if we change the shape of a class
and remove the history of said class, it breaks unless we reregister
with the new version of the class.