# om

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

oconn 01:28:46

Question about om-next / Datomic interaction. I'm sending my requests from the client over transit+json and I want to leverage Datomic's pull syntax. I have this working when I define all the parameters I want, but I am having difficulties using wildcard syntax. Anyone have a suggestion or link to an example if this is possible?

oconn 01:29:59

example of what I want to be able to define on the client: (:user/by-id '[* {:user/permissions [*]}])

oscar 01:39:34

I don't believe wildcards are allowed since they're written as a symbol and afaik only keywords and maps are allowed in a query. Also, the point of queries are for the components to specify what they expect and wildcards would break that. Just declare all the keywords you need.

oconn 01:43:06

That makes sense, thanks.

pedroteixeira 03:46:48

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?

tony.kay 04:54:14

which will be welcome

oscar 07:27:27

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

fenton 19:22:27

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

wilkerlucio 19:40:51

@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])

fenton 19:43:32

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

wilkerlucio 19:44:27

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)

wilkerlucio 19:44:47

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

fenton 19:47:12

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

wilkerlucio 22:04:09

@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