This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # aleph (1)
- # arachne (10)
- # beginners (6)
- # boot (81)
- # braveandtrue (3)
- # cider (42)
- # cljs-dev (1)
- # cljs-edn (52)
- # cljsjs (9)
- # cljsrn (9)
- # clojure (62)
- # clojure-austin (1)
- # clojure-belgium (11)
- # clojure-berlin (2)
- # clojure-gamedev (2)
- # clojure-greece (1)
- # clojure-russia (73)
- # clojure-uk (98)
- # clojurescript (156)
- # community-development (4)
- # component (3)
- # cursive (30)
- # datascript (10)
- # datomic (17)
- # emacs (5)
- # events (1)
- # hoplon (315)
- # jobs (1)
- # jobs-discuss (3)
- # lein-figwheel (6)
- # luminus (18)
- # off-topic (13)
- # om (130)
- # other-languages (122)
- # re-frame (32)
- # reagent (27)
- # rethinkdb (6)
- # ring (2)
- # ring-swagger (31)
- # spacemacs (4)
- # untangled (6)
- # yada (30)
I’d like to pass a database connection into the scheduled jobs, but I don’t think the context is a good way of doing that
I guess I’ll use defrecord instead of defjob and pass in the database there, also does not seem very idiomatic though
general architecting question: my users can schedule a recurring service at a certain frequency (daily, weekly, monthly) kind of like google calendars recurring events. Note, I'm using MongoDB, so relational stuff is a little more difficult, but I could change the db if needed. 1.) When a user makes a new recurring service, should I populate a global "queue" (in a db) with the times of that service a few years out? (then if they cancel/modify their service, I walk through all the pre-made events to change them) 2.) Or should I do a cron job every morning that walks over every user and determines if they should have a scheduled service today and adds today's service to a sort of "queue"? 3.) Something else?
@josh.freckleton: I like the 1st solution, with 2nd, cancelling out or modifying services will be difficult something like “this event everyday but not tomorrow
or probably , u can have a mix of 1 and 2. global queue for near future. and running cron job less frequently than a day.
@josh.freckleton: If 1. is possible depends mainly on the library for synchronization. IIRC there are scheduling libs that will have a delay on recurring events over the time. Also, if you go for that solution, you will have to rebuild the "services" on every restart of your application from scratch, which could take its time, depending on your solution
@sveri "rebuild services every restart" only if the queue was in memory right? But I would probably have the "queue" in a db, or am I mistaken?
@josh.freckleton: I guess you will need a mix, longterm events in a persisten storage and the "short" term services in memory
@pcbalodi: mix is probably the way to go. Maybe cron job determines this weeks schedule, and then certain functions can modify the "queue" @sveri: the client that needs to look at the queue of services will probably just poll the "queue" and the short term services will be in his browser/app's memory
Does anyone have a good embedded datastore they'd suggest? I'm working on a game rule system of sorts, and I need to store records describing the various entities in the game. I've been using core.logic's pldb to structure records as a bunch of fact tuples sharing an ID value and I've found this to be... difficult to reason about. Suggestions would be appreciated.
does anyone know if there already exist an implementation of GraphQL for Closure ?
@seancorfield: Have you run Java.jdbc tests on Postgres lately? I'm seeing lots of failures
Yes. I'm trying to debug a problem with insert! not working without transaction, but while running java.jdbc tests pretty much everything fails so I'm not sure if there is something wrong with my setup.
Anyway, I'm seeing a potential problem in this commit,
:transaction? used to default to true if the option was not given, now there is no default value: https://github.com/clojure/java.jdbc/commit/310781429225b614cab01256f3adce54917644aa#diff-3a9a3475f16407a50d922fad53957b01L945
In that commit
transaction? default value is set in
insert! but that code is removed in latter comit
I am seeing errors locally as well, looks like the tests are trying to create the fruit table over and over, but it already exists
the fixture that is supposed to drop the table in between tests is swallowing exceptions
ah, because all the deletes are now happening in a transaction, when one of the deletes fails, the rest don't happen, and of course you would only see this in postgres because I doubt any of the other dbs tested against have transactional ddl
Yeah, thanks. Now I'm seeing other problems because in postgres insert returns the rows instead of just ids.
Is there a commonly used convention for naming atoms? I generally write my code in a way that passes around the dereferenced atom’s value rather than the atom but it’s not immediately clear when you’re dealing with the atom or its value
@akjetma: never found such convention either, my way to do it is prefix it with
@hiredman: what's wrong with underscores? I like the visual contrast they provide
i have experimented with a single trailing earmuff, appending
-state to the atom, appending
val to its value. It all feels dirty
the difference between the atom and the value is the value is a value, and the atom is a reference or identity, so you can use that to make up a name
clojure names typically eschew underscores for hyphens, and many clojure programmers have a preference for hyphens, to the point that at my last job there was a big push to run everything (from json, or a database) through a conversion function so the names in the map were more clojure like, which made it easier to bind clojure style names using destructuring
wait a sec, i think i just realized why it feels especially dirty with the thing i'm working on. i have an atom/value that i want to call
db because it is used as a shim for a database. so distinguishing between the value and state of a thing called
db is an extra layer of weirdness.
I didn't particularly care for that, I think it was a waste, but it goes to show how deep the preference runs
@hiredman: I like to have the possibility to use both as separators, just as I like the fact that Clojure syntax has both lists and vectors - nice for contrast. But I get that some people may view it as dirty
there are, in fact, some bugs related to and -, last I checked (which was a few years ago) which cause things to explode if you try and let bind both ab and a-b if I recall correctly
@juhoteperi: Sorry, I’ve always relies on others testing
java.jdbc against Postgres quickly enough to catch failures early… but several regular Postgres testers seemed to have moved on (either from using Postgres or using Clojure, I don’t know) and I no longer get any feedback on it.
I’m happy to fix any Postgres-related problems if folks can give me enough pointers — or a patch! — to get things working again.
There was talk of having Postgres available on the Clojure CI system so it would get tested there… but in the end that never happened, as far as I know.
I guess I could use Docker to have a Postgres environment for testing. I do test against MS SQL Server (using both the MS Type 3 driver and jTDS) with a Windows XP VM running on my Mac!
I created JDBC-129 to get a PostgreSQL test environment up and running. Then it can be a standard part of my testing in future. And you’re right about the transactional DDL — that’s just a silly bug to attempt to rely on that since it is not transactional in many (most?) DBs.
One solution to running tests would be to use CircleCI, they have Postgres and MySQL available 🙂