resource and data with zodb

21 views
Skip to first unread message

wilk

unread,
Jul 25, 2015, 8:26:49 AM7/25/15
to pylons-...@googlegroups.com
Hi,

I'll try to explain my question (sorry for my english)...

I use zodb like the wiki example to store my pages, supages and so on.
The tree is in root['app_root']

Now i would like to store data to the same zodb database, users,
customers.
Where and how should i put them ?

I think in root['mydata']. Right ?
But how to access root again ? with context and __parent__ i can access
the top of root['app_root'] but not root['mydata']. Or i can with
context._p_jar.root but i'm not sure it's the right way to access it.

Should i call zodb.get_connection(request) and use a root['mydata'] ?

Also i don't understand why in the example the transaction is commited
explicitly in root_factory. It will be not be commited automaticaly
after ?

Thanks for advices, i would like to use the right way.

--
William

Mike Orr

unread,
Jul 25, 2015, 10:33:54 AM7/25/15
to pylons-...@googlegroups.com
I have't used ZODB with Pyramid so I'll let others answer most of the
question, but you're on the right track with ``root["app_root"]`` and
``root["mydata"]``. The database is not just to store pages but to
store all data the application needs. You wouldn't say that PostgreSQL
should store only pages and have no non-page tables, so why would one
prohibit the same in ZODB? There may be valid security reasons to keep
certain data outside the page structure so it can't accidentally be
seen by URL. The way to do this is to put the Pyramid resource root at
a subkey in ZODB rather than right at the ZODB root. Your
``root["app_root"]`` does this, and I assume you can make a Pyramid
root_factory that returns this node. Then you can put your data under
``root["mydata"]`` or any other key(s) you wish.

One thing to keep in mind is that the nature of ZODB's storage
mechanism makes it good for some kinds of data but not for others.
It's great for hierarchical data structures that SQL is inconvenient
for, and it's nice to persist Python data types without having to
explicitly pickle them or convert them into an alien data structure.
But its append-only nature makes it unsuitable for counters and things
that change a lot in place. But it can be used alongside other storage
mechanisms that have different strengths. For instance, Redis is
superior for counters. because it can change an item in place very
frequently with no data-size overhead.
> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
> To post to this group, send email to pylons-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/pylons-discuss.
> For more options, visit https://groups.google.com/d/optout.



--
Mike Orr <slugg...@gmail.com>

Jeff Dairiki

unread,
Jul 29, 2015, 10:49:08 AM7/29/15
to pylons-...@googlegroups.com
If you're thinking about using ZODB in a new pyramid-based app, definitely look into SubstanceD, which provide pre-built admin UII (and more) for ZODB-based web apps.

Reply all
Reply to author
Forward
0 new messages