Re: "Members site", how to set up?

On 2015-03-05 06:06, Jean Jordaan wrote:
> On Wed, Mar 4, 2015 at 3:30 PM, Alessandro Pisa
> <[email protected]> wrote:
> [...]
>> The experience I had let me think that:
>>   - flat data structures should go in relational DB (user data)
>>   - nested structures should go in object DB (user contents)
>> This is why I would instead use heavily postgres to save/query user
>> data and simply use folders for storing member contents.
>
> @jensens, would a https://github.com/bluedynamics/souper.plone backend
> for this kind of flat data make sense?
>

souper is for sure a variant to store users with all its properties. 
since each soup has its own catalog its also easy to search and list 
through users. adding user properties would be souper-easy, same with 
adding new search indexes for this properties if needed.
also it would not be a problem to deal with several 100k users. each 
soup can be put on an own mount-point, so zodb-cache gets optimized.

anyway, theres no PAS plugin yet implemented using souper: somebody 
would have to write it. this is no rocket sience, but for sure work. PAS 
apis are not that much fun. so if theres a budget ping me, i'am happy to 
implement this :)

Pros
+users stay in zodb
+easy extensible
+only zodb dependency
+reusable in other python webframeworks (see also 
https://vimeo.com/110590834)

Cons
-users storage not reusbale outside python world.
-theres PAS implementation

regards Jens
-- 
Klein & Partner KG, member of BlueDynamics Alliance


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/