[Glass] how to update models properly

Sebastian Heidbrink via Glass glass at lists.gemtalksystems.com
Wed Oct 29 13:33:41 PDT 2014


Hi John, James, Dale and Richard,

thank you so much for the vast amount of information.

@Dale
The tODE approche is tempting and I will definitely consider it for a 
part of my project. I assume it is not the perfect way for an interface 
that should also aloow access to non smalltalk cilents.
I also guess that security related implementations might become too 
dfficult once one would allow the block based protocol. ('(Smalltalk 
exceptTheStuffINeedToCommit) become: nil') ;-)

@John
Thank you! I never saw somebody using the writeLock: mechanism. I assume 
that this is THE MOST CONFILCT PROHIBITIVE WAY to do things.  I assume 
this will prevent you from headaches once you work with several gems...
I might consider using this approach combined with James idea
Thank you also for the insight to your backup script.

@James
That sounds interesting. I never thought about that. I assume that 
approach is only used on non collection based attributes.

@Richard
Well, this is something I have in mind for some parts of my tool, but 
yet it is still beyond my experience when it might make sense to have 
such mechanism or not.
I think I need to start small and let first usecases decide where it is 
needed or not ;-)

Thanks to John I came accross the old Seaside Examples like the Sushi 
Store! I'll analyze implementations in there, too.

So I will do my research based on your thoughts and try to find a way to 
wrap my brain around it :-D
All the Best
Sebastian



Am 29.10.2014 10:22, schrieb John McIntosh:
> Sebastian as you are not using seaside, you should read thru
> http://gemstonesoup.wordpress.com/2008/03/09/glass-101-simple-persistence/
> and understand the part on object locking.
>
> So for example on an incoming request I take my handy unique 
> identifier from the client, look it up, if found it's an update so I do
>
> basicDataChangedWithLock: fields
> "WASessionLockNotAcquiredException when signalled will cause the 
> initial HTTP request to be retried after
> an abortTransaction"
> System writeLock: self
> ifDenied: [
> WARetryHttpRequest signal: 'SerialNumber lock denied'.
> "does not return"  ]
> ifChanged: [
> System addToCommitOrAbortReleaseLocksSet: self.
> WARetryHttpRequest signal: 'SerialNumber lock changed'.
> "does not return" ].
> self basicDataChanged: fields.
> System addToCommitOrAbortReleaseLocksSet: self.
>
> The basicDataChanged: then takes the dictionary of key/value pairs and 
> compares against the current data. Given I work with items such as the 
> name of the iOS device I make heavy use of symbols to store that 
> information.
>
>
> Other issues are relate to the backup, for that I have this script, 
> which I think needs some work as it sometimes hangs in the while loop 
> if a GemTools session is active.
> Also because I only have a few 10 of millions of objects I can do the 
> "SystemRepository Audit"  This also then pushes the current backup to 
> Amazon S3 which archives it after a week to Glacier.  Not shown is 
> another script that takes the output log file and builds a JIRA entry 
> so in the morning I can jump over to JIRA and confirm the backup 
> worked as expected.  Note the s3cmd also does a PGP encryption on the 
> data before sending, the --server-side-encryption is redundant but 
> there out of habit.
>
> Note once a year or so the object audit reports an issue with a few 
> objects, but running the audit again after taking the database out of 
> production along with a page audit shows no issue. I was told it could 
> be a transit issue.
>
>
> /opt/gemstone/product/bin/topaz -l -T 50000 << EOF
>
> set gemstone seaside
>
> set username DataCurator
>
> login
>
> swordfish
>
> output push backup.out
>
> errorCount
>
> run
>
>  System waitForVoteStateIdle.
>
>  [ System _deadNotReclaimedCount > 0 ] whileTrue: [ System sleep: 1.  
> System abortTransaction ].
>
> %
>
> send SystemRepository objectAudit
>
> send SystemRepository startNewLog
>
> run
>
>  SystemRepository fullBackupCompressedTo:
>
>  '/opt/gemstone/backups/backup-' ,
>
>  (DateTime now asSeconds // 60) printString.
>
> %
>
> logout
>
> errorCount
>
> exit
>
> EOF
>
> # cleanup backups
>
> cat backup.out >> backupAll.out
>
> cd /opt/gemstone/backups
>
> ls -l
>
> find . -maxdepth 1 -daystart  -mtime -1  -type f -exec 
> /usr/local/bin/s3cmd --server-side-encryption --reduced-redundancy -e 
> put {} s3://foobartoobar \;
>
> #
>
> (ls -t backup* | head -n 2; ls backup*) | sort | uniq -u | xargs rm
>
> if [ "2" -le "`find . -mtime -2 -name 'backup*' | wc -l`" ]; then
>
>  cd /opt/gemstone/product/seaside/data
>
>  find . -maxdepth 1  -mtime +2  -name 'tranlog*' -exec rm {} \;
>
> fi
>
>
>
>
>
> On Wed, Oct 29, 2014 at 9:40 AM, Richard Sargent via Glass 
> <glass at lists.gemtalksystems.com 
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>     Hi Sebastian,
>
>     If you replicate state between different memory spaces, you have
>     the same kind of issues to deal with that GBS faces. There *are* a
>     lot of complexities in the general case.
>
>     Ultimately, when you send the revised state back to the server,
>     you need to ensure you update the existing server object with the
>     replicated data. The Object database model is very different from
>     the Relational database model (which has an essential indirection
>     built-in).
>
>     It may be worth considering executing behaviours in the server
>     against the object (and then replicating the new state back to the
>     client).
>
>     On Wed, Oct 29, 2014 at 9:23 AM, Sebastian Heidbrink via Glass
>     <glass at lists.gemtalksystems.com
>     <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>         Hi all,
>
>         I spent quite some time to get used to Gemstone now . Somehow
>         I stumble across some questions and insecurities again and again.
>
>         I wonder if somebody can give me some hints on this.
>
>         I use Gemstone/Web without Seaside but with a ZincREST
>         interface. Some of my data model objects a transfered via JSON
>         or CSV betwenn db and client. Everytime the client wants to
>         modify data on the server he sends a JSON representation of
>         the object to the server and the server parses the json and
>         creates a data model object from it.
>         Now I do have a persited version of my model object and the
>         just newly created model object within the DB.
>         How would I update now? I can't replace the persisted object
>         by the new one, because I might loose references to/from it...
>         I will need to walk through all attributes compare them and
>         replace just different ones?!
>         I feel like the whole approache is wrong and slow, isn't it?
>         Wouldn't it be better to just parse the request's json into a
>         JSONObject and do the synching after I located the persisted
>         Object based on some hash values or id provided?
>
>         How do your strategies look like? I currently feel like
>         producing too many temporary and unneeded objects.
>
>         Creade, Delete and Replace do not really provide such
>         "imagination" issues like the Update... do they?
>
>         Any push into the right direction is highly appreciated!
>         Thanks and have fun at FAST if you'll be there!
>         Sebastian
>         _______________________________________________
>         Glass mailing list
>         Glass at lists.gemtalksystems.com
>         <mailto:Glass at lists.gemtalksystems.com>
>         http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
>     _______________________________________________
>     Glass mailing list
>     Glass at lists.gemtalksystems.com <mailto:Glass at lists.gemtalksystems.com>
>     http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
>
> -- 
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com 
> <mailto:johnmci at smalltalkconsulting.com>> 
> https://www.linkedin.com/in/smalltalk
> ===========================================================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20141029/84bed7dd/attachment-0001.html>


More information about the Glass mailing list