Fork me on GitHub
#yada
<
2015-10-30
>
stijn10:10:29

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

stijn10:10:33

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

stijn10:10:24

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

malcolmsparks14:10:30

parameter coercion is done in malformed?

malcolmsparks14:10:44

which runs before check-modification-time

malcolmsparks14:10:03

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

malcolmsparks14:10:16

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

malcolmsparks14:10:43

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

malcolmsparks14:10:09

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

stijn14:10:00

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 :))

stijn14:10:30

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

stijn14:10:01

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

stijn14:10:07

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

malcolmsparks14:10:21

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

malcolmsparks14:10:24

it's a catch 22

stijn14:10:29

maybe last-modified should not be a property?

malcolmsparks14:10:01

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

stijn14:10:05

😄

malcolmsparks14:10:06

this stuff ain't easy

malcolmsparks14:10:39

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

stijn14:10:45

I guess so

stijn14:10:57

get-more-properties 😛

malcolmsparks14:10:02

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

malcolmsparks14:10:09

exactly, it gets a bit complex

malcolmsparks14:10:37

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

malcolmsparks14:10:44

they should be in :route-params

stijn14:10:00

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

stijn14:10:43

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 ...

stijn14:10:41

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

malcolmsparks14:10:01

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

stijn14:10:24

and then reuse the result in GET

stijn14:10:30

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

stijn14:10:11

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

stijn14:10:31

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

malcolmsparks15:10:09

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

malcolmsparks15:10:17

gotta go - talk later