Fork me on GitHub
#clojure-dev
<
2016-04-12
>
mpenet06:04:44

@seancorfield: in my experience you're better off breaking the api and do some cleanup than adding opts to change the current signatures. As long as it is well documented, semver'ed and you provide short/effective upgrade guides it should be ok.

seancorfield15:04:57

@mpenet: I agree in principle but in reality, with large code bases, I’ve found having interim versions that can warn you about deprecations to be more effective.

seancorfield15:04:51

And I have no problem with overloading the future, intended, signatures of 0.6.0 with backward compatible signatures in the 0.5.x releases so I can issue warnings of code that will stop functioning in 0.6.0.

seancorfield15:04:13

Having slept on the API issues, I’m definitely leaning toward introducing an options map for db-do-prepared so that :multi? can be specified and making it compatible with execute! in that regard (so [sql-string param param param] is the default and [sql-string [param param] [param param] [param param]] is the :multi? true form).

seancorfield15:04:34

(and it seems almost no one here cares about java.jdbc enough to offer an opinion — which is fine… I know regular SQL/JDBC databases seem to be dramatically less popular in the Clojure community than I’m used to in other communities 😸 )

shaun-mahood16:04:49

@seancorfield: I care about java.jdbc simple_smile Don't have any usage of do-prepared, but I think the options map sounds like a solid plan and it seems as bit more straightforward than more overloading.

bja16:04:30

@seancorfield: I know a bunch of people using java.jdbc (I'm one of them), but like all of the other people I know, I don't use it directly (there are functions or macros that let me send honeysql structures, handle quoting, etc). If the api changes one day and I have to adapt my wrapper function to use a slightly different calling convention, I don't think I'm more strongly than a -0 (would prefer to not do the work, but it's fine and doesn't affect me that much one way or another).

seancorfield17:04:49

We use HoneySQL extensively at World Singles and the format it generates — [sql-string param param param] — is the one that I’m trying to standardize the whole library on, and most of the updates to our own code to avoid the deprecated calls were around insert!, with just a handful of other places. And that’s because we use :entities and :identifiers a lot. If we didn’t use those at all, I don’t think we’d have need to make many changes (again, a handful of insert! calls where we were inserting multiple rows in a single call.

ghadi17:04:42

seancorfield: I should contribute my reducible result-set code to you

ghadi17:04:49

s/you/java.jdbc

ghadi17:04:02

but you'd have to drop 1.6

seancorfield17:04:08

You posted it in one of the tickets I think?

ghadi17:04:10

which is probably a non-starter?

ghadi17:04:16

I've improved it since then.

seancorfield17:04:34

Yeah, we’re not ready to drop that many Clojure releases. We only dropped 1.3 recently.

ghadi17:04:14

Also had a "readers" option for the resultsets like clojure.edn readers so that you can get back stuff like java.time dates instead of java.sql

ghadi20:04:35

(defn progression
  "Returns a reducible and seqable source of values. The predicate
  `continue?` determines whether to produce another value using `f`."
  {:added "1.9"}
  [continue? f seed]
  (reify
    clojure.lang.Sequential
    clojure.lang.Seqable
    (seq [_]
      (let [step (fn step-fn [seed]
                   (cons seed (lazy-seq
                                (when (continue? seed)
                                  (step-fn (f seed))))))]
        (step seed)))
    clojure.lang.IReduceInit
    (reduce [_ rf init]
      (loop [ret (rf init seed)
             seed seed]
        (if (reduced? ret)
          @ret
          (if (continue? seed)
            (let [next (f seed)]
              (recur (rf ret next) next))
            ret))))))

ghadi20:04:26

Can I get some 👀 on that as an impl for unfold? ( 👋 @hiredman @alexmiller )

ghadi20:04:15

The reduce side of it does not reuse any values cached from the seq side of it.

ghadi20:04:02

example usage:

(vec (progression pos? dec 5))
;; [5 4 3 2 1 0]

ghadi20:04:39

name can obviously change

seancorfield21:04:49

Well there are already protocols you can extend to provide custom data conversion - in both directions - https://clojurians.slack.com/archives/clojure-dev/p1460483234000241

seancorfield21:04:38

clj-time uses that to provide Joda Time compatibility with java.jdbc.

ghadi21:04:09

protocols are global

seancorfield23:04:23

Yes, true dat. So are types, right? 😸

seancorfield23:04:01

But providing a per-call way to handle such conversions is an interesting idea… Maybe open a JIRA ticket to discuss in more detail?

seancorfield23:04:24

Most of what java.jdbc tries to do is via per-call options (passing in functions etc).