[Glass] how to update models properly

John McIntosh via Glass glass at lists.gemtalksystems.com
Wed Oct 29 10:22:13 PDT 2014


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> 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> 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
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>


-- 
===========================================================================
John M. McIntosh <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/d5b77566/attachment.html>


More information about the Glass mailing list