Re: [pylons-discuss] Best practices for running Pyramid (docker) and nginx (host) deployment

[Jens Troeger]

Oh, and more question… Monitoring.

For example, to monitor Dramatiq ’s asynchronous 
workers it provides a middleware 
 for 
Prometheus  to gather metrics. What’s does the 
community recommend for Pyramid to monitor its metrics? Didn’t see anything 
on Projects  page or the Awesome 
Pyramid  page.

Or is it better to hook up Prometheus to the nginx reverse proxy (link 
),
 
which, however, in my case runs outside of the app container on the host 樂

Much thanks,
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/a3a27a0e-703f-4384-aec7-a89fc95137a1n%40googlegroups.com.

Re: [pylons-discuss] Best practices for running Pyramid (docker) and nginx (host) deployment

[Jens Troeger]

Thank you, everyone!

@Theron, yes I meant “forwardED”, just a typo. I’ll review the 
configuration and try again. Regarding the Docker link: my project has 
heaps of dependencies that I offloaded into another base image, so I think 
I won’t be able to build on top of yours.

@Michael, glad to know that waitress 
 
works in production. I’ll take a look at the docs once more to find out 
where things are hanging for me…

@Andreas, thank you for the url_scheme tip, if the X-Forwarded-Proto doesn’t 
work, I’ll try that one too.

Cheers,
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/0323d4d1-0746-483e-8d97-e8488dd14b95n%40googlegroups.com.

[pylons-discuss] Best practices for running Pyramid (docker) and nginx (host) deployment

[Jens Troeger]

Hello,

I’ve seen some conversation here about running a Pyramid app server inside 
a Docker container, but none has really answered my questions.

My setup is that nginx runs on the host and currently uses *proxy_pass* 
 to 
forward requests to the container’s external port, so that the requests are 
then processed and responded to by the Pyramid application running inside 
the container.

*Question*: Inside the container I’m running the Pyramid application using 
pserve 

 
which listens on the container’s mapped internal port. Should I switch to 
gunicorn  instead? Does it matter in 
such a setup?

The *proxy_pass* URL is http://127.0.0.1:6543 which means that the external 
https gets lost. That, in turn, means that within the Pyramid app (inside 
of the container) calls to e.g. static_url() 

 
return a http route instead of the necessary & expected https.

*Question*: I currently use prefix WSGI middleware to rewrite responses (
discussion 
) but 
that feels hacky. Unfortunately, I wasn’t able to make X-Forward-Proto 
 
HTTP 
header work quite yet so what’s the current recommendation here? Is the Using 
Behind a Reverse Proxy 
 
page current and working?

*Question*: Are there any benefits to using a UNIX socket for *proxy_pass*, 
instead of HTTP?

Much thanks in advance!
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/508f077e-ff7e-47c4-9e8f-ee5f018e9a7en%40googlegroups.com.

[pylons-discuss] GET, HEAD, the Guillotine middleware extension

[Jens Troeger]

Hello,

Today I stumbled upon a somewhat dated Pylons project called Guillotine 
, a WSGI middleware 

 
extension. It seems to have only one purpose: rewrite the request method of 
HEAD requests into GET.

Now I am curious about the *why*. A HEAD request is, as per documentation 
, pretty 
much a GET without body. So what’s the purpose then of this particular 
extension and the rewrite?

Much thanks,
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/cd9466d9-47ce-410f-9b36-5a47417cf8f2%40googlegroups.com.

[pylons-discuss] Is there a catch-all “predicate mismatch” view?

[Jens Troeger]

Hello,

During testing we just noticed that existing views whose predicate 
mismatched when making a request return an error like so:

404 Not Found
The resource could not be found.

predicate mismatch for view ... (request_method = POST)

Is there a way to define a view that matches any and all of such mismatches 
to avoid returning too much information to the client? At least for 
production…

Cheers!
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/78b7b977-8c47-481b-8488-21c223888a26%40googlegroups.com.

[pylons-discuss] How to handle SQLA autoflush failures during Request commit?

[Jens Troeger]

Hello,

I’m using gunicorn  in front of a Pyramid server, 
and I changed the configuration from 1 to 4 workers. Now I occasionally see 
the following exception:

InvalidRequestError: This Session's transaction has been rolled back due to 
a previous exception during flush. To begin a new transaction with this 
Session, first issue Session.rollback(). Original exception was: (raised as 
a result of Query-invoked autoflush; consider using a session.no_autoflush 
block if this flush is occurring prematurely)
(pymysql.err.OperationalError) (1213, 'Deadlock found when trying to get 
lock; try restarting transaction')
[SQL: UPDATE … SET foo=%(bar)s WHERE …]
[parameters: {…}]
(Background on this error at: http://sqlalche.me/e/e3q8)

The server follows the SQLA cookie-cutter template 
, and is running 
with a SQLAlchemy Session factory 

 
whose autoflush 

 
still defaults to true. Curiously, it seems that only one particular 
endpoint keeps triggering this problem, and the failing UPDATE attempts to 
flip a boolean flag.

However, the exception gives rise to two questions:

   1. *SQLAlchemy perspective.* The reason for using autoflush here is to 
   ensure that new ORM objects whose primary key is generated like so:
   id = Column(UUID(), default=uuid.uuid4, primary_key=True)
   have a valid id after they’ve been newly created. Would using a manual 
   dbsession.flush() be preferable with autoflush disabled? Are there better 
   recommended ways of handling this problem? (See this related question 
   
   .)
   2. *Pyramid perspective.* Every Request object has its own Session 
   object associated which commits when request handling is done. However, the 
   above exception in a sense *fails* the request handling. If I was to 
   follow the suggestion to “begin a new transaction with this Session” then 
   how would I do that? Does Pyramid provide existing support to handle such 
   issues, or does the exception indicate a problem elsewhere that requires 
   attention? What is best practice here?

In general, I think I’d like to understand the finer details of 
SQLAlchemy’s autoflush and how that interplays with Pyramid’s requests and 
their Sessions and transactions. I wonder, for example, if the above 
indicates that a client has sent the same request more than once (Android’s 
httplib seems to do that), and with more than one workers enabled this 
manifests a race condition.

Much thanks!
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/e0201c58-f801-42c6-93e8-a3bb08e9a230%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Velruse… or what else?

[Jens Troeger]

Thank you Michael for sharing your insights here. I’ve looked through some 
of the code but, as you said, the testing looked rather daunting to me.

On top of that, it's actually really easy (imo) to consume OAuth 2.x + 
> OpenID Connect apis directly. Most bindings for velruse end up being just a 
> very thin wrapper around a small amount of code you can easily write 
> yourself. It basically just involves implementing a redirection endpoint 
> that the provider will send the browser to once the user has granted 
> access, and from there taking the token and querying whatever you want from 
> the provider's api. OpenID Connect has helped a lot in standardizing the 
> type of data you'd want to receive - something velruse was trying to 
> standardize before that standard existed.
>

This statement of yours aligns nicely with my thoughts/suspicion that 
perhaps I ought to drop Velruse altogether, and instead use an OAuth2 
package to talk with the providers directly. The website uses only Google, 
LinkedIn, Live anyway (and I’m thinking to add Apple now) and they all—I 
think—speak OAuth2.

The recent OAuth thread 
 
recommends requests-oauthlib … 
Can you recommend any particular package, is the that one good?

Much thanks!
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/d1292058-f1d9-48a7-8068-e5f290199bf8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Velruse… or what else?

[Jens Troeger]

Hi,

Interesting OAuth thread here 
, thank 
you! And just in time for my question.

I’ve been using Velruse  quite happily 
for a while now, although it’s been stale for a few years. MichaelM 
 was somewhat active on that project too, and 
he still seems to be around working on Pylons in general.

However, a few things could need updating with Velruse (see its issues 
) and now that Apple has 
released a sign-in API, it would be nice to add that to Velruse as well.

So I was wondering: are there plans to continue working on Velruse, maybe 
integrating it closer into Pyramid? Are there more recent alternatives? Are 
there people here who are using Velruse?

Much thanks,
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/59d49299-53d7-4439-98d5-3d93627cb8f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Relationship between requests and Zope transactions

[jens . troeger]

Thank you Mike for the information, that all makes sense. I ended up with 
the same approach that SQLA takes: a “Session” object owned by a 
DataManager, joined to the Request’s TransactionManager. And then just pass 
a `dbsession` and `fnsession` and `jobsession` around to functions as 
needed.

Added yet another one or two parameters (sigh) to functions, but it keeps 
things functional and without outside (global, thread-local) state.

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/148c7bec-2d75-4525-9aa4-3902a4a2f2cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Relationship between requests and Zope transactions

[jens . troeger]

Maybe some background… the reason why I asked the initial question is 
because a few (and a growing number of) request handlers are complex; that 
is, they call multiple function levels deep.

Now request.dbsession, for example, is SQLA’s current DB session tied to 
the request’s transaction. To get access to it, functions keep handing that 
`dbsession` reference around. As we now begin to tie more data managers to 
the request’s transaction, handing their context around convolutes the 
parameters handed to functions.

So I thought it would be useful if much/all of a request’s execution 
context would be available through the current thread local 
 memory. 
However, reading Why You Shouldn’t Abuse Thread Local 

 (see 
the pyramid.threadlocal 

 
module) recommends against such an approach. Are there more recent and 
different recommendations?

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/5b86bb49-8fb5-4ebe-ad2b-c3a4da52bad3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Relationship between requests and Zope transactions

[jens . troeger]

Maybe some background… the reason why I asked the initial question is 
because a few (and a growing number of) request handlers are complex; that 
is, they call multiple function levels deep.

Now request.dbsession, for example, is SQLA’s current DB session tied to 
the request’s transaction. To get access to it, functions keep handing that 
`dbsession` reference around. As we now begin to tie more data managers to 
the request’s transaction, handing their context around convolutes the 
parameters handed to functions.

So I thought it would be useful if much/all of a request’s execution 
context would be available through the current thread local 
 
memory. If requests during their life cycle 
 
would derive from threading.local and initialize such a storage area upon 
construction (e.g. after tween ingress) and tear it down (e.g. after tween 
egress) then deeply nested function could still access a request’s context 
*without* the need to pass that context around in parameters.

Would it make sense to use a custom request factory to implement such a 
thread local approach? Are there other recommendations, considering the 
warnings in pyramid.threadlocal 

?

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/080f5943-b2df-4d6c-8b49-ab5cfa7bbe6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Relationship between requests and Zope transactions

[jens . troeger]

Thanks Michael!

You are talking about these two lines of code 

 in 
the cookiecutter’s model/__init__.py, correct?

settings = config.get_settings()
settings['tm.manager_hook'] = 'pyramid_tm.explicit_manager'

That manager hook allocates its own explicit transaction manager (see code 
)
 
instead of using the transaction.manager default, as you’ve mentioned.

Using that manager hook I can then derive from an explicit manager and 
extend with custom functionality—and that would be the recommended way of 
doing so? That may help me solve a question I just asked at the transaction 
Github repo (see issue #62 
 there).


On Sunday, September 2, 2018 at 9:04:58 AM UTC+10, Michael Merickel wrote:
>
> Jens, by default your example is true, but it is not true in the 
> cookiecutter configuration. The value of request.tm is defined by the 
> tm.manager_hook setting and by default it is the threadlocal 
> transaction.manager. The cookiecutter overrides the hook (and I suggest you 
> do as well) to define a non-threadlocal manager configured in explicit=True 
> mode which will help weed out bugs accessing transactions after they have 
> been committed. I strongly suggest any code you write that needs the tm 
> should use request.tm, not transaction.manager - as the former is 
> configurable.
>
> - Michael
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/0f690504-4a20-42c7-a10e-0da915e602b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Relationship between requests and Zope transactions

[jens . troeger]

Hi,

According to the documentation here 
, “Pyramid 

 
requests [to] join the active transaction 

 
as provided by the Python transaction 
 package”. Looking at the 
transactions code, the default transaction manager used is a 
ThreadTransactionManager 
,
 
i.e. one transaction per Python execution thread.

Now I did follow the Pyramid-SQLAlchemy-Cookiecutter 
 recipe where DB 
sessions join the request’s transaction. Considering that a single incoming 
request is handled in Pyramid by a single thread (correct?) is it safe to 
say that the following is true?

import transaction

@view_config(…)
def some_view(request):
   # Request's transaction manager is the thread's transaction manager.
   request.tm == transaction.manager
   # Request's and thread's and tm's transaction is the same object.
   request.tm.get() == transaction.get()  # == transaction.manager.get()

Thanks!
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/79da9d5a-91e9-483e-b96f-b5e54cc3f1a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Re: How to send task-message after request.tm has committed?

[jens . troeger]

Hello Thierry,

You are talking about these data 
managers: http://zodb.readthedocs.io/en/latest/transactions.html#data-managers 
Correct? Other than the Mailer  
it seems a little difficult to find more verbose documentation?

I have played a little more with the after-commit hook and this short piece 
of code seems to work:

@view_config(
…
)
def some_view(request):
  
# Do some view stuff, modify db objects, etc.

# Local helper function that issues the message to the broker. This
# function has access to the closure but beware that db objects are
# committed and invalid!
def _send_message(success, *args, **kwargs):
if success:
# Send message to the broker, thus spawning a worker task.
dramatiq_actors.some_task.send(*args)  # Or Celery tasks, 
whatever.

# Get the transaction for this request.
t = request.tm.get()

# Arguments for the task.
args = (
foo,
3,
)
kwargs = {}

# Add the after-commit hook, i.e. call _send_message() when the
# request's transaction has committed.
t.addAfterCommitHook(_send_message, args=args, kws=kwargs)

# And return from the view function.
return {
"some": "results",
}

It looks to me that this is an acceptable solution if the called hook 
function can not fail (i.e. return success/failure) and therewith can not 
contribute to the transaction to fail/succeed. However, a data manager 
solution makes sense if data must be managed and processing/persisting that 
data may fail which impacts the overall transaction.

Any recommendations here?

Cheers,
Jens


On Friday, June 1, 2018 at 5:06:35 PM UTC+10, Thierry Florac wrote:
>
> Hi,
> Maybe you should have a look at the "DataManager" component interface 
> provided by the "transaction" package.
> This kind of component allows you to include your hook in a "two-phase 
> commit" transaction safely.
> Several implementations are available, for example in the 
> "repoze.sendmail" package...
>
> Best regards,
> Thierry
>
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/7f6ccda4-865f-4070-9610-dc5f691ba8e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Re: How to send task-message after request.tm has committed?

[jens . troeger]

Poking around the documentation some more, it seems that using an 
after-commit-hook 
 
may work: i.e. when a task needs to be scheduled by the view function, then 
find the request’s transaction (from `request.tm`?) and install the hook 
function and and its arguments (i.e. which task needs to be scheduled and 
the task’s args).

But still, what is the official and recommended way of solving this? 樂

Cheers!

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/25d30da3-5079-46f7-b15a-2ffe3d44c06e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] How to send task-message after request.tm has committed?

[jens . troeger]

Hi,

Within a view function it becomes necessary to run an async task. Celery 
, Dramatiq , etc are 
frameworks to handle that. However, my async task needs to read db objects 
which have been created—and must be committed and persisted—by the view 
function that spawns the task. Thus, I need to delay spawning the task 
(i.e. sending the task’s message to the workers) until after the request’s 
db transaction has committed.

The db transaction is a standard SQLAlchemy transaction. Using the commit 
veto hook 

 
is too early. This SO answer 

 
suggests using the repoze.tm.after_end() 
 callback, but the 
answer is about five years old now.

How do I handle this scenario correctly, i.e. how do I schedule an async 
job after a request was successful? I guess I can pack up the task object, 
or a signature, and its parameters and attach them to the request from 
within the view function. But where is the right place to actually send the 
task message?

Thanks!
Jens


-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/ef6bf67d-acec-4dae-b318-7749743add31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] DB QueuePool limit overflow and Pyramid sub-requests

[jens . troeger]

Thank you for the explanation, Jonathan! No, I didn't use *use_tweens* and 
perhaps will give that a try.

However, considering our other conversation 
 
regarding the requests package and how to issue API calls within a view 
callable, I’ll switch to using that anyway.

Jens



On Wednesday, May 2, 2018 at 3:38:10 AM UTC+10, Jonathan Vanasco wrote:
>
> Are you passing in `*use_tweens=True*` ?
>
>
> https://docs.pylonsproject.org/projects/pyramid/en/latest/api/request.html#pyramid.request.Request.invoke_subrequest
>
> https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/subrequest.html?highlight=use_tweens#subrequests-with-tweens
>
> If not, the behavior you show is expected.  `pyramid_tm` handles the 
> transaction begin/commit via tweens.  If the subrequests don't use the 
> tweens, they're part of your main transaction and don't close the 
> dbconnection or return it to the pool.  So they will require 1 db 
> connection for main + [1 db connections for each subrequest].
>
> If you are not enabling tweens in the subrequest, then Pyramid doesn't 
> work how I'd imagine it to.  But this behavior makes sense for pyramid_tm 
> without tweens enabled.
>
> Sidenote: I don't know if transaction/pyramid_tm can handle subrequests 
> like this.  You might want the functionality that Michael Merickel 
> suggested above, by copying over the main db session.
>
> Like most others though, I avoid subrequests at all costs. 
>
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/7ab21cf5-f387-4b2d-b644-0dc263c2397a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Re: Suggested way to issue requests from inside a view callable

[jens . troeger]

Thank you everybody, requests it is then! 

On Wednesday, May 2, 2018 at 2:40:29 AM UTC+10, Jonathan Vanasco wrote:
>
> If your synchronous tasks are done "quickly" or must be "blocking" -- like 
> doing some oAuth or hitting an external API that is guaranteed to return a 
> request within a second or two, I would just use `requests` from within 
> Pyramid.
>

Yup, quick API calls that can be blocking.

 
On Wednesday, May 2, 2018 at 2:40:29 AM UTC+10, Jonathan Vanasco wrote:

> If you're concerned with extended processing on your end, or not using 
> systems that guarantee a response within a given amount of time... I would 
> use Pyramid to trigger a Celery task, and then have the page reload every 5 
> seconds to poll the Celery backend for status.
>
 
Jonathan, funny you mention Celery. I have used it for a while but the 
experience has been horrible—the thing is ridden with bugs and problems, 
barely maintained, and the list of issues on Github grows daily. Which is 
why I raised this 
discussion: 
https://stackoverflow.com/questions/46517613/python-task-queue-alternatives-and-frameworks

Curious though, I rolled the Celery task integration myself because I 
didn’t find any specific module for Pyramid. Is there some explicit support 
module out there?

Cheers,
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/f07117af-3200-44ed-a89b-cbfc724dcf77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Suggested way to issue requests from inside a view callable

[jens . troeger]

Hello,

I guess following up on the thread on Pyramid’s sub-requests 
, what is the recommended way to issue a 
(synchronous) request to an external server from within a view callable? 
Using the requests  package, or 
are there Pyramid plugins available (didn’t find any at first glance).

Thank you for recommendations…
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/75f3cb8f-7984-445a-b0fc-e7ffda1a7768%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] DB QueuePool limit overflow and Pyramid sub-requests

[jens . troeger]

Jonathan,

On Monday, April 30, 2018 at 4:17:50 AM UTC+10, Jonathan Vanasco wrote:
>
> How are you handling your session connection and cleanup?  Are you using 
> pyramid_tm? If so, are you using the `use_tween` on the invoke_subrequest 
> to properly close each connection in the pool?  If not, how are you 
> cleaning up your connections?
>

I’ve followed the suggested cookie cutter code 
exactly: https://github.com/Pylons/pyramid-cookiecutter-alchemy, which uses 
pyramid_tm and adds the SQLA session to that transaction manager.

Thanks!
Jens 

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/c8f29336-c224-453c-923f-15e0df5ead5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] DB QueuePool limit overflow and Pyramid sub-requests

[jens . troeger]

Hi Jonathan,

Assuming you have 1 request and 5 subrequests, shouldn't there only be 2 
> connections needed in the pool (i.e. the main request establishes a first 
> connection, then subrequest 1 establishes a second connection which is 
> re-used by 2-5)?  You wouldn't be able to save a connection like this if 
> you had recursive subrequests - but that would be a design flaw in the 
> application logic.
>

>From within the view function (i.e. handling the incoming request) I issue 
5 subrequests one after the other. Doing so I noticed that the number of 
subrequests was bound by the pool_size + max_overflow, hence my question 
here and in the SQLA group. 
 

> If you're connecting to sqlalchemy during your setup, you can screw up the 
> connection pool unless you call `engine.dispose()` (see a thread from a few 
> weeks ago), because SqlAlchemy's connections and pool aren't forksafe or 
> threadsafe.
>

I'm not sure what you mean here: "during setup" meaning when the app 
starts, or when the request is being handled?

Cheers,
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/d476c9da-d45b-4530-b342-ff408fb0ef2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] DB QueuePool limit overflow and Pyramid sub-requests

[jens . troeger]

Thank you Michael,

In general I strongly urge you to reconsider using subrequests... they are 
> there for people to use but they have lots of drawbacks versus just calling 
> a bunch of reusable functions.
>

What would you recommend then to issue a request from within a view 
function? Using something like the requests 
 package?

Cheers,
Jens 

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/570274fd-0ea3-4258-a9e0-719684b2b4cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] DB QueuePool limit overflow and Pyramid sub-requests

[jens . troeger]

Hello,

Perhaps this forum is more appropriate to ask than the SQLAlchemy group 
(see this same question over there 
).

I would like to understand the interplay between a SQLA session and a 
Pyramid’s subrequest 
.
 
When a request is handled, a new session is created for that request as per 
the Pyramid/SQLA cookiecutter 
, and it looks to 
me like subrequests create a new session too.

When I set the pool_size 

 of 
the engine to *N* and max_overflow 

 to *M* then I can issue only a max of *N+M* subrequests, after which I get 
an exception:

Traceback (most recent call last):
  File "/…/site-packages/sqlalchemy/pool.py", line 1122, in _do_get
return self._pool.get(wait, self._timeout)
  File "/…/site-packages/sqlalchemy/util/queue.py", line 156, in get
raise Empty
sqlalchemy.util.queue.Empty

During handling of the above exception, another exception occurred:

[…]
  File "/…/site-packages/sqlalchemy/engine/base.py", line 2147, in 
_wrap_pool_connect
return fn()
  File "/…/site-packages/sqlalchemy/pool.py", line 387, in connect
return _ConnectionFairy._checkout(self)
  File "/…/site-packages/sqlalchemy/pool.py", line 766, in _checkout
fairy = _ConnectionRecord.checkout(pool)
  File "/…/site-packages/sqlalchemy/pool.py", line 516, in checkout
rec = pool._do_get()
  File "/…/site-packages/sqlalchemy/pool.py", line 1131, in _do_get
(self.size(), self.overflow(), self._timeout))
sqlalchemy.exc.TimeoutError: QueuePool limit of size 5 overflow 0 reached, 
connection timed out, timeout 30

for 

sqlalchemy.pool_size = 5
sqlalchemy.max_overflow = 0

When I up the pool size to fit all subrequests, then everything works fine 
and the SQLA log shows me a ROLLBACK for each subrequest and one COMMIT at 
the end which I think is the main request.

Now I could set pool size to 0 to indicate no pool size limit, but I’m not 
sure if that would be the correct solution here.

What’s the recommended approach here?

Thanks!
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/6c2f13c2-ea4d-4f9d-9d47-50dc98c6e583%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] route_url() to generate a URL with …/#/… (for Javascript)

[jens . troeger]

Hi,

Using request.route_url() I’m trying to generate a URL of the form: 
_app_url/#/foo?arg=bla

Using a route="/#/foo" escaped the hash, and so did "/{hash_}/foo", and 
that's according to the change comment 

 
for Pyramid v1.9. Furthermore, an _anchor is always placed *after* query 
string arguments and must not be empty, so using _anchor="" is also not an 
option.

The best I can come up with is assembling such a URL like so:

_app_url + "/#/foo?" + pyramid.url.urlencode({"arg": "bla"})

but that looks rather ugly.

What is the recommended way of generating such a URL string? (Leaving aside 
the sense or nonsense of such a URL…)

Thanks!
Jens


-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/09785b15-32f1-4f9a-98f5-67b77caa0080%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Re: What’s the type of `request` in an exception view?

[jens . troeger]

After some more tinkering: the `request` parameter is of type 
*pyramid.util.Request* which is derived from *pyramid.request.Request*, so 
using isinstance() is safe.

As per this example 
,
 
my request instances have a *user* attribute which is a SQLAlchemy ORM 
instance tied to the request’s db session (see here 
).
 
The odd thing that I’ve observed in the exception view is the following: 
*sqlalchemy.inspect(request.user).detached* is False, but then 
*request.user.profile* raises an exception.

I have to mention that the exception that enters the exception view is a 
*sqlalchemy.exc.IntegrityError*, i.e. the db session has been rolled back 
at the time when the exception view is entered. Should I check the db 
session’s is_active 

 
attribute inside of the exception view function, i.e:

def handle_exception(exc, request):
if request.dbsession.is_active:
# Safe to use request.user.
else:
# The exception raised in a view function caused the DB session
# to flush or roll back--either way it's not usable anymore.

Thanks!


On Saturday, January 27, 2018 at 2:29:00 PM UTC-8, jens.t...@gmail.com 
wrote:
>
> Hello,
>
> I’ve got the following exception view:
>
> @view_config(
> context=Exception,
> permission=NO_PERMISSION_REQUIRED,
> )
> def handle_exception(exc, request):
> """Last resort view function."""
> …
>
> I had assumed that the `request` parameter here is the same instance as 
> the `request` parameter from the view function that raised the exception. 
> However, that does not seem to be the case. (In fact, the SQLAlchemy 
> session bound to the view function’s request has been expired by the time 
> the exception view is entered.)
>
> While a normal view function’s `request` parameter is of type 
> *pyramid.request.Request*, the exception view’s is of type 
> *pyramid.util.Request*. Which doesn’t seem to exist though: *AttributeError: 
> module 'pyramid.util' has no attribute 'Request'*
>
> It would be helpful if the docs would shed more light on this. Any more 
> details would be great!
>
> Thanks!
> Jens
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/2f922a5b-a325-4bf3-9bea-81cdf4f974d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] What’s the type of `request` in an exception view?

[jens . troeger]

Hello,

I’ve got the following exception view:

@view_config(
context=Exception,
permission=NO_PERMISSION_REQUIRED,
)
def handle_exception(exc, request):
"""Last resort view function."""
…

I had assumed that the `request` parameter here is the same instance as the 
`request` parameter from the view function that raised the exception. 
However, that does not seem to be the case. (In fact, the SQLAlchemy 
session bound to the view function’s request has been expired by the time 
the exception view is entered.)

While a normal view function’s `request` parameter is of type 
*pyramid.request.Request*, the exception view’s is of type 
*pyramid.util.Request*. Which doesn’t seem to exist though: *AttributeError: 
module 'pyramid.util' has no attribute 'Request'*

It would be helpful if the docs would shed more light on this. Any more 
details would be great!

Thanks!
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/7595cf58-f523-4c4e-b78e-5e64850d6e9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Confused with parameter `request` in exception views.

[jens . troeger]

Hello,

Following the examples of how to implement an exception view (see here 

 
or here 
),
 
I have the following code:

@view_config(
context=Exception,
permission=NO_PERMISSION_REQUIRED,
)
def handle_exception(exc, request):
"""Last resort to handle view exceptions."""
…

However, as it turns out the `request` parameter passed into the above view 
function is a ** and not an instance of 
*pyramid.request.Request*. Yet, printing the request parameter dumps 
request information.

It would be good if the documentation would shed more light on this 
behavior. I had assumed that the request parameter is the same *Request* 
instance from the view function where the exception was raised. But that 
seems not to be the case?

Thanks,
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/30257edc-8516-44cb-ac6d-a02d8107565f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Re: pyramid webdav example?

[jens . troeger]

This question is somewhat dated and still unanswered.

I’d like to renew it though: has anybody in the meantime been playing 
around with WebDAV  (or its derivates 
CalDAV  and CardDAV 
), maybe added the additional verbs 
perhaps in a Cornice -like fashion? Or 
any other experience implementing WebDAV with Pyramid?

Initial googling, binging, yahooing hasn’t brought up anything noticeable.

Thanks!



On Tuesday, May 19, 2015 at 7:41:53 AM UTC+10, kris wrote:
>
>
> Anybody have a quick webdav server written with pyramid?
>
>
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/488296a3-203c-40f4-9de5-3f4f5cc461c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] How to handle DB transaction failures/request race conditions

[jens . troeger]

Hello,

Looking at the SQLAlchemy cookie cutter 
, a request gets 
its own transaction-backed db session, and on its way out a response 
commits that transaction and closes the session. There are activation 

 
and veto 

 
hooks too.

I'm trying to understand the details behind the request/response ↔ db 
session/transaction interaction.

During ordinary operation, everything should work just fine and all 
modifications to ORM objects during a view functions commit with the 
response. But what happens when a transaction fails, for example because of 
a CHECK constraint?

How exactly are race conditions handled: suppose two requests to the same 
endpoint at the same time, both create the same resource, one of which 
fails (well, should!) to commit. When and how is that handled?

Thank you for pointers and tips and hints in advance 邏
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/2a39e5b2-d8fa-43be-891c-4b1cd48d465e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Attaching custom header to all responses

[jens . troeger]

Hi, 

This question is more of a curious one as I explore different possible 
solutions for a problem.

What is the recommended way of adding an X-Myapp-Didum header to *every* 
response returned from the server? It looks like there are different ways 
to achieve that:

   - Change the Response factory 
   
:
 
   inherit from the Pyramid Response class and add the header in __init__;
   - Use a Response callback 
   

 
   which adds the header whenever a response is returned from a view function;
   - A Finished callback 
   
,
 
   like the Response callback, can add the header to the request.response 
   object.

It looks like the Response factory is the favorable way to go, considering 
that both callbacks seem to work only on a per-request basis? Or what other 
ways exist to achieve this?

Thanks!
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/2f333583-13ff-4587-a11d-b81e47948109%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] How to enable JSON renderer as default for all views?

[jens . troeger]

Thanks Michael!

Would you like me to submit a PR for the adjusted comment as per your 
suggestion?

All of my (Cornice) view functions are decorated like so:

@some_service.post(
 
content_type="application/json",

accept="application/json",  

…
)

which I think asks for the json renderer for responses. Unless, if I 
understand you correctly, the returned object is response object (instead 
of a dict or None or whatever).

So should I then use

def some_view_fun(request):
…
request.response.status = 201 # Created
return None

instead of returning a HTTPCreated() here? 

Thank you!
Jens


On Thursday, November 2, 2017 at 1:48:02 AM UTC+10, Michael Merickel wrote:
>
> This renderer feature does not override the other one which is "if you 
> return a Response object then no renderers will be invoked". HTTPOk is a 
> Response subclass. This is covered in the first few paragraphs of the 
> renderer chapter. I'd be open to a PR that clarified the docs on this in 
> the section you linked since it does say "all views". It is infact "all 
> views that do not return something directly adaptable to a response such as 
> an implementer of IResponse, or an object whose type is registered as a 
> response adapter".
>
>
> https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/renderers.html#renderers
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/a89934fa-d7a5-487d-8790-0f370e999cbd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] How to enable JSON renderer as default for all views?

[jens . troeger]

Hello,

The documentation for the default renderer for all views 

 
seems to suggest that the following should work:

from pyramid.renderers import JSON

config = Configurator(
…
)
config.add_renderer(None, JSON())

Alas, when one of the views returns HTTPOk() the response type is still 
html. How to I make JSON the default renderer here for *all* views?

Thanks!
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/d730910a-2425-48fa-841b-4f891ddc525e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Proper handling of views for ACL roles

[jens . troeger]

Thank you, Michael, exactly what I was looking for :-)

I understand your point of mutually exclusive roles for predicates, but 
seeing that `effective_principals` takes a list, I assume that I can use 
multiple roles for the predicate?

Cheers,
Jens


On Monday, October 16, 2017 at 11:04:56 AM UTC+10, Michael Merickel wrote:
>
> It seems you're asking about how to affect the "view lookup" [1] phase of 
> the request.
>
>
> https://docs.pylonsproject.org/projects/pyramid/en/1.9-branch/narr/router.html
>
> The "permission=" is not a predicate and thus cannot be used as part of 
> view lookup to select between various views. The way to do what you're 
> asking (assuming that your role-based principals are mutually exclusive) is 
> to use the "effective_principals=[some_role]" predicate which *will* allow 
> view lookup to continue until a view that matches is found. The reason I 
> say they must be mutually exclusive is that view lookup is effectively 
> unordered and thus values for a predicate are expected to be tested without 
> respect to other registered views with similar predicates.
>
> - Michael
>
> On Sun, Oct 15, 2017 at 6:51 PM,  
> wrote:
>
>> Hi,
>>
>> I'm using Cornice  and Pyramid 
>>  for my REST API server, and followed 
>> the standard authorization examples using ACLs 
>> .
>>  
>> For example:
>>
>> # The Cornice service.
>> bills_service = Service("bills", "/api/bills", factory=BillsListContext)
>>
>> # The Context factory:
>> class BillListContext(object):
>> def __init__(self, request):
>> pass
>>
>> @property
>> def __acl__(self):
>> return [
>> (Allow, "role:buyer", "get_bills"),
>> (Allow, "role:seller", "get_bills"),
>> ]
>>
>> # And the view function is then:
>> @bills_service.get(
>> content_type="application/json",
>> accept="application/json",
>> permission="get_bills",
>> )
>> def get_bills(request):
>> # …
>>
>> The view implementation now contains role checks (if 
>> request.user.role...) and services requests depending on the requesting 
>> user's role. 
>>
>> My question is: is there a better way to implement views for different 
>> roles? How would I decorate view functions, each for a specified role? What 
>> is the recommended way here?
>>
>> Thanks!
>>
>> -- 
>> 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 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/pylons-discuss/605159f6-1461-4dd4-b133-88d7f0748795%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/88898120-47dd-4333-a688-f8cc0ce843dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Proper handling of views for ACL roles

[jens . troeger]

Hi,

I'm using Cornice  and Pyramid 
 for my REST API server, and followed 
the standard authorization examples using ACLs 
.
 
For example:

# The Cornice service.
bills_service = Service("bills", "/api/bills", factory=BillsListContext)

# The Context factory:
class BillListContext(object):
def __init__(self, request):
pass

@property
def __acl__(self):
return [
(Allow, "role:buyer", "get_bills"),
(Allow, "role:seller", "get_bills"),
]

# And the view function is then:
@bills_service.get(
content_type="application/json",
accept="application/json",
permission="get_bills",
)
def get_bills(request):
# …

The view implementation now contains role checks (if request.user.role...) 
and services requests depending on the requesting user's role. 

My question is: is there a better way to implement views for different 
roles? How would I decorate view functions, each for a specified role? What 
is the recommended way here?

Thanks!

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/605159f6-1461-4dd4-b133-88d7f0748795%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] How do I "forward" requests and switch their contexts?

[jens . troeger]

Hello everybody,

I could need a bit of help with a more architectural question. I'm using 
Cornice  to build a REST server on top 
of Pyramid/SQLAlchemy. Now I've got two main "domains" in my endpoints, 
which are accessed by the two different user roles in the system:

 - Normal users have endpoints like /api/user/profile, etc
 - Administrator users have endpoints like /api/admin/user/profile, etc.

Obviously, each "domain" has its own set of endpoints; however, sometimes 
the endpoints overlap. For example, assume the two endpoints above. A 
normal user may POST her name to /api/user/profile to change the name in 
her own profile. An administrator, in contrast, has to specify both the 
user *and* the name of the user in their POST request to change the name 
for a given user.

This is essentially duplicated functionality, where the only difference is 
the context.

How would I best go about implementing such a scenario without duplicating 
code for the two requests?

It would make sense to "forward" the normal user request to the view 
handler of the admin, unless this elevation of rights would be frowned 
upon. Alternatively, one could "forward" the admin request to the view 
function of the normal user. Either way, the context data would have to be 
adjusted but that is a small effort compared to the duplicated code. Or 
should I uses common helper functions, which would still mean to duplicate 
code that validates incoming request data?

So what is the recommended way of going about such scenarios?

Thanks!
Jens

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/fec47c51-6f57-4608-8ec6-239eccfaedd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pylons-discuss] Re: New Pyramid Celery integration implementation

[jens . troeger]

Thank you for this thread, good pointers!

I'd be curious to hear your opinions to this code review 
request: 
http://codereview.stackexchange.com/questions/148872/integrating-celery-task-queue-with-pyramid/

Thanks!


On Sunday, August 21, 2016 at 8:41:35 PM UTC+10, Mikko Ohtamaa wrote:
>
> Hi all,
>
> After struggling with this for few years I think I have finally nailed 
> Pyramid and Celery integration. The design goals include
>
> * No global variables or import time side effects. Everything is set up 
> through Pyramid registry using venusian compatible @task decorator.
>
> * Configured through INI settings
>
> * Kick off delayed task on transaction commit
>
> * Transaction retries in the case the task runs into database conflict 
> resolution
>
> * Support for eager execution
>
> * Support for scheduled (beat) tasks
>
> * Celery 4.0+ compatible
>
> Here: http://websauna.org/docs/narrative/misc/task.html
>
> If there is market demand I might factor this out to a separate package
>
> -- 
> Mikko Ohtamaa
> http://opensourcehacker.com
> http://twitter.com/moo9000
>
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/5f182324-5f78-4ac7-a395-079a0266b91b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.