Clojurians Log v2

isn't it wrong that om/transact! returns a map? it looses ordering and actions with same name.. it'd be better if it would return a list of [{:result ..} ..}, no?

@pedroteixeira om/transact! isn't a database transaction; if one mutation fails, it doesn't roll back all of the changes in the transaction. Therefore, there's no benefit to running all of your mutations in the same transaction. If you want to maintain ordering and preserve the results of mutations with the same name, just run them all in different transact! statements. However, you shouldn't have a reason to ever need the result of a mutation unless you're resolving tempids from a remote. If you need the value of something, just add it to your application state and retrieve the value using queries.

i'm trying to implement the simple use case of validating a user by sending a username password combination to the backend. Question 1: should this be a transaction or a query? This isn't information that shows up in the UI, so I thought I could do as a transaction and merge the results into the app-state atom. Should this rather be a parameterized query passing in parameters username/password, and query for a key like :user/authenticated (true/false).

@fenton use a transaction to send the the information, if you need to get some data after it use a follow up query, eg: (om/transact! '[(auth/login {...}) :app/current-user])

@wilkerlucio ok I'll try that. :app/current-user is the query that is occurring in the ?same? transaction?

is not on the transation, it's something after it, remember that transactions don't return any data (currently the exceptional case is the tempids replacement, but you should not count on transaction returns for anything else at this point)

imagine that you can query :app/current-user at any time, but if the user is not logged in you get nil, otherwise you get the user

ok. then I guess I'll have to create some sort of token on the clientside to pass through in a parameterized? query, so I can distinguish this user from other users...

@fenton well, it will depend on your implementation, but usually this is done with browser session/cookies, so you don't have to do much besides set it on your server side