[Seaside] Mongo/Voyage singleton vs instance mode and seaside Request filters

Sabine Manaa manaa.sabine at gmail.com
Thu Feb 16 13:00:57 UTC 2017


Hi,

the last days we had a an interesting discussion on slack. 
Stephan Eggermont asked me to post a summary here for discussion,
Information and because of the 10.000 messages limitation of slack:

Situation:
Til now I used Mongo/Voyage in singleton mode [1]. That means in short that
I had one single database/repository in mongo. I then decided that I want to
have one database/repository per customer (one customer has n persons) and
one "super-database/repository" for data like currencies valid for all
customers and for lookup of the right database for each user/email address.
This has a lot of advantages. Mongo allows to have n databases/repositories
within one installation.

First, I thought, that I have to change my code from

"aPersonInstance save" 
(this is the singleton mode way, always same repository)

to "aCustomerRepository save: aPersonInstance"
(instance mode - so that mongo knows which repository to use)

Then Esteban proposed to use a SeasideFilter. This would be a lot better.
He told me to create a subclass of WARequest Filter and implement:

"handleFiltered: aRequestContext
    VOCurrentRepository 
        value: self obtainSessionRepository
        during: [  self next handleFiltered:  aRequestContext]

obtainSessionRepository
    ^ self session 
    propertyAt: #repository 
    ifAbsentPut: [ self newRepositoryForUser ]

newRepositoryForUser
   ^  VOMongoRepository database: 'client-database'"

He also implemented and released some more code for this (e.g.
VOCurrentRepository) [2].
The idea/concept is, that seaside uses the right repository within the
current request context  and one does not have to deal with the 
repositories.

Udo Schneider suggested the DynamicVariable subclass and get it within the
WACurrentRequestContext

I did not know/use about Seaside Filters and not about DynamicVariables, so
it was very interesting.

Currently I think that perhaps for me overwriting the save method (I have a
superclass of all my voyage root objects) would be sufficient for me. My
customers repository is set at login and kept in the session.

RKAObject>>save
    | theRepository |
    theRepository := [ WACurrentRequestContext value session
customerRepository ]
        on: WARequestContextNotFound
        do: [ :ex | nil ].
    theRepository save: self.

But I am not finished with this and opinions are welcome and perhaps this is
useful for others.
 
There was a lot more discussion. I will put the whole discussion from slack
in an answer of this post. So it is kept but not attached in answers to THIS
post.

Sabine


 [1]
http://files.pharo.org/books-pdfs/entreprise-pharo/2016-10-06-EnterprisePharo.pdf
chapter on voyage
[2]https://github.com/pharo-nosql/voyage/commit/d1fa97e41470671452d3501421a7bd0ac60456e9




--
View this message in context: http://forum.world.st/Mongo-Voyage-singleton-vs-instance-mode-and-seaside-Request-filters-tp4934578.html
Sent from the Seaside General mailing list archive at Nabble.com.


More information about the seaside mailing list