@malcolmsparks: I have a question on the interceptor get-properties

I understand you need it to determine method-allowed?, but e.g. for last-modified it would be nice to have the parameter coercion already inside the context

you need to query something in the db / filesystem / ... based on the parameters of the request

Hi @stijn

Hi

parameter coercion is done in malformed?

which runs before check-modification-time

so you're saying you'd like malformed? to run before get-properties?

but get-properties provides the data on which malformed can operate

If you can figure out a different ordering that allows everything to work that would be very welcome

I'm not 100% sure what you're asking, could you perhaps add some clarification?

the use case is this: let's say I have some data in the db with a 'updated' timestamp (it's mongodb, so not as smart as datomic on this front :))

I want to send back last-modified based on this field, but in order to do that I need to query the db, with e.g. the given object id, which is parsed from the parameters

or maybe I don't understand the :last-modified of the resource properties?

when 'get-properties' is executed, it calculates the last-modified timestamp, but at that time there are no parsed parameters available yet

yes I see

the path properties are in the request, just not been processed or coerced

it's a catch 22

maybe last-modified should not be a property?

indeed

welcome to the fun of figuring out the order of yada interceptors!

😄

this stuff ain't easy

perhaps it needs to be broken out into more than one interceptor

I guess so

get-more-properties 😛

it's a trade-off between ease-of-use and understanding, and meeting all requirements

exactly, it gets a bit complex

for now you do have access to the request, so you can pull out the path parameters

they should be in :route-params

yes, that's what I'm doing right now

one thing that's also not really clear to me is, how do you avoid query the db multiple times e.g. for :exists?, :last-modified and the final (GET ...

in liberator that would typically happen in the exists? call, and you'd assoc something into the context which you would use later on

that was the thinking behind get-properties, one trip to the database

ok

and then reuse the result in GET

btw I created a branch where you can specify your custom interceptor through the options of the handler. good idea or not?

it obviously does not follow updates to the default interceptor chain in future yada version then

but I created it now because authentication / authorization is commented out

yes, that's ok. I've been working hard on async streams (in and out) and it's taken much longer than I hoped, but I'll be coming back to auth soon

gotta go - talk later

bye