Dormo 2018-10-24T00:21:46.000100Z

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

Dormo 2018-10-24T00:22:01.000100Z


Dormo 2018-10-24T00:22:06.000100Z

try removing one colon

Dormo 2018-10-24T00:22:36.000100Z


Dormo 2018-10-24T00:22:41.000100Z

that's cider code

Dormo 2018-10-24T00:22:50.000100Z

and it looks like this was fixed

Dormo 2018-10-24T00:22:58.000200Z

What version of Cider are you running?

Dormo 2018-10-24T00:24:35.000100Z

Hope some of this information helps


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


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


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


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


These are the deps on that project:


(output from lein deps :tree)


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

jcb 2018-10-24T11:41:58.000100Z

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?

jcb 2018-10-24T11:59:23.000100Z

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

yogthos 2018-10-24T14:10:45.000100Z

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

yogthos 2018-10-24T14:11:46.000100Z

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

yogthos 2018-10-24T14:13:18.000200Z

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

jcb 2018-10-24T14:18:30.000100Z

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

jcb 2018-10-24T14:18:32.000100Z

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

jcb 2018-10-24T14:21:18.000100Z

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

jcb 2018-10-24T14:21:41.000100Z

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

jcb 2018-10-24T14:29:14.000100Z

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

yogthos 2018-10-24T15:12:56.000100Z

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

yogthos 2018-10-24T15:13:41.000200Z

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


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:


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


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

jcb 2018-10-24T15:48:28.000100Z

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

yogthos 2018-10-25T21:09:26.000100Z

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

yogthos 2018-10-25T21:10:56.000100Z

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

jcb 2018-10-24T15:49:12.000100Z

how would I explicitly remove the session?

jcb 2018-10-24T15:51:04.000100Z

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

jcb 2018-10-24T15:53:09.000100Z

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


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

jcb 2018-10-24T16:05:12.000100Z

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


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


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.

llsouder 2018-10-25T12:32:53.000100Z

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

Dormo 2018-10-24T21:48:51.000100Z

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