Fork me on GitHub
#luminus
<
2018-10-24
>
Dormo00:10:46

@credulous >Error loading cider.nrepl.middleware.test: java.lang.RuntimeException: Invalid token: ::clojure.test/once-fixtures, compiling:(cider/nrepl/middleware/test.clj:103:57)

Dormo00:10:01

::clojure.test/once-fixtures

Dormo00:10:06

try removing one colon

Dormo00:10:41

that's cider code

Dormo00:10:50

and it looks like this was fixed

Dormo00:10:58

What version of Cider are you running?

Dormo00:10:35

Hope some of this information helps

credulous00:10:03

Right. In my original project the Luminus setup was forcing cider-nrepl 0.10.1

credulous00:10:01

I wasn’t sure how - it’s not in the project.clj anywhere, and it’s listed as a top-level dependency when I run lein deps :tree

credulous00:10:32

So that’s the way it is in that vanilla test project I pasted above

credulous00:10:15

But in my project I added [cider/cider-nrepl “0.18.0”] to the project dependencies, which overrode whatever was insisting on 0.10.1

credulous00:10:16

These are the deps on that project:

credulous00:10:50

(output from lein deps :tree)

credulous00:10:11

and I still get an error, but a different one.

jcb11:10:58

How do you extend the session timeout in the default luminus template? the ring-ttl-session docs suggest there could be a performance hit. Would ignoring it entirely be a better option?

jcb11:10:23

I'm using reagent and secretary on the frontend. Would a forced re-direct re-new the session?

yogthos14:10:45

@jcb if you're using immutant (default http server) it leverages jboss sessions and those are quite fast

yogthos14:10:46

The ring-ttl-session is mostly recommend for other servers such as jetty or http-kit, and the performance with it is still quite decent

yogthos14:10:18

The session is managed by a cookie, so if you wanted to renew it, you'd want to clear the cookie on the client, or remove the session on the server explicitly, the latter is the recommended approach

jcb14:10:30

I am using immutant, it's pretty much the generated scaffold other than an asset path tweak so my wrap base looks like this -

jcb14:10:32

(defn wrap-base [handler] (if-let [asset-path (:asset-path env)] (-> ((:middleware defaults) handler) wrap-webjars wrap-flash (wrap-session {:cookie-attrs {:http-only true}}) (wrap-defaults (-> site-defaults (assoc-in [:static :files] asset-path) (assoc-in [:security :anti-forgery] false) (dissoc :session))) wrap-internal-error)) )

jcb14:10:18

I guess my use is a bit of an edge case, it's for a set of kiosked locally hosted displays so the session expiry messes with the communication with the database

jcb14:10:41

and there is no way for the user to refresh the page

jcb14:10:14

thanks for your explanation @yogthos but I'm unsure how to proceed

yogthos15:10:56

yeah so you are using the immutant session already, and you shouldn't see any performance problems there

yogthos15:10:41

could you explain the workflow a bit more, how is the session lifecycle supposed to work?

credulous15:10:24

Hi, I hate to repeat myself, and if my problem is unsolvable I’ll move on. I’ve created an app with +mysql, and only modified the database url - i.e. I haven’t touched the default migration. When I run lein run migrate I get an error in migratus saying that the query is empty:

credulous15:10:20

Migratus has created and populated the schema_migrations table, so I think the db and url are correct.

credulous15:10:43

Also, when I cut-and-paste the command above into the mysql console, it works fine

jcb15:10:28

I'm getting 403 returns from my post requests after about 30 minutes of inactivity, and I'm not sure how to stop this from happening

yogthos21:10:26

the easiest option would be to switch to using a cookie based session without expiry

yogthos21:10:56

in that scenario you wouldn't have a server-side memory session at all, and all the session information would be tracked by the cookie, there are examples in the official Ring docs here https://github.com/ring-clojure/ring/wiki/Sessions

jcb15:10:12

how would I explicitly remove the session?

jcb15:10:04

hi @credulous I was having weird problems with migratus yesterday too. Have you tried deleting the schema_migrations table or rollback?

jcb15:10:09

I had to generate new migrations and start again but I've been fine with subsequent migrations

credulous15:10:40

Thanks @jcb, yeah I’ve actually been dropping and recreating the database each time.

jcb16:10:12

I'm using sqlite so I'm not sure what if those ssl warnings are significant

credulous20:10:54

I’ve gotten rid of the warnings but the problem remains. I turned on trace debugging and migratus.migration.sql has the query right to the bitter end. But the call to clojure.java.jdbc/db-do-commands fails.

credulous20:10:15

Feeling pretty idiotic - on my third day trying to get a basic fullstack app going. Clojure the language is awesome but I’m finding the dev environment very difficult.

Dormo21:10:51

Once you get things going, it's insanely nice. I agree that getting started is frustrating, though. Even once I got things working it took me some time to figure out how to architect the application without a more opinionated framework

llsouder12:10:53

I just had this same experience! I was doing too much. I got mine working by letting the templates do everything and learning more about the user namespace and my new favorite command (keys (ns-publics 'user))