I also like the new api design. You can just jdbc/execute! and jdbc/query
everything. Or almost. I was trying:
(jdbc/execute!
["INSERT INTO fruits (name, color, flavor) VALUES (?, ?, ?)" ["apple"
"red" "sweet"] ["pear" "yellow" "sweet"]])
But that doesn't work. Should it? I know that jdbc/insert! works but it's
not the same.
On Tuesday, April 9, 2013 7:41:10 PM UTC-3, Sean Corfield wrote:
>
> On Tue, Apr 9, 2013 at 1:49 PM, r0man
> <roman....@burningswell.com<javascript:>>
> wrote:
> > first off, I like the new API design.
>
> Thanx.
>
> > 1.) Despite the asymmetry I'm also thinking that passing entities
> > and identifiers functions via the "db" argument is quite
> > convienient. Otherwise I always have to wrestle with those extra
> > parameters and pass them through my underlying SQL generation
> > functions. Which I have to to with the db anyway (maybe one level
> > less).
>
> Could you elaborate on your use case, in the context of the new API?
> I'm trying to imagine what "my underlying SQL generation functions"
> look like and how they relate to / have access to the db-spec.
>
> The identifiers and entities macros allow you to wrap a block of code
> containing the new API and/or the DSL and have the functions injected
> automatically:
>
> (entities (quoted \')
> ...
> (insert! my-db :foo {:name "Bar" :level 123})
> ...
> (identifiers as-is
> ...
> (query my-db (select :name :foo (where {:level 123})))))
>
> That is equivalent to the (much longer):
>
> ...
> (insert! my-db :foo {:name "Bar" :level 123} :entities (quoted \'))
> ...
> (query my-db (select :name :foo (where {:level 123} :entities
> (quoted \')) :entities (quoted \')) :identifiers as-is)
>
> ;; assuming I got my parens right!
>
> Given that SQL generation happens _before_ the db-spec is even
> referenced - and happens in a separately evaluated form - I'm not
> seeing how having :entities inside the db-spec helps here.
>
> > 2.) The default naming strategy for columns coming from the
> > database is at the moment "lower-case". Wouldn't it be more
> > idiomatic to lower case and replace "_" with "-".
>
> Yes, but I didn't want to break backward compatibility (with the
> default behavior of 0.2.x and earlier) since I expect people to
> migrate easily and that seems like a gratuitous change, because it
> would ripple thru all of the library's client code. I'm certainly
> happy to provide a convenience function in the DSL, along with as-is,
> lower-case, and (quoted x) to provide lower-case-and-hyphens in the
> entity to Clojure direction (i.e., an identifiers function) and an
> as-is-with-underscore in the opposite direction... with better
> names... suggestions?
>
> I believe the defaults in java.jdbc have always been (effectively):
> * :identifiers lower-case
> * :entities as-is
>
> I don't want to make migration from 0.2.x to 0.3.0 difficult for folks
> with large code bases (like me, for example!).
>
> > 3.) Would it make sense to define some connection spec, into
> > which the current specs get translated to? Something like the
> > Ring SPEC for connections. I'm often interested in the name of
> > the database, the credentials of the hostname the database is
> > running on, etc. Something like this?
>
> An interesting idea...
>
> As it stands, the API functions all accept anything that
> get-connection can turn into a database connection, and from a
> connection you can get the catalog and quite a bit of metadata (via
> .getCatalog and .getMetaData method calls). Some of the things you can
> pass to get-connection don't directly contain the information you're
> looking for (e.g., pass in a JNDI name / environment or a DataSource
> object with username / password - not to be confused with the
> user/password property used in some of the other "connectable"
> things).
>
> Feel free to add notes or comments here:
> http://dev.clojure.org/display/design/java.jdbc
> Also request enhancements here:
> http://dev.clojure.org/jira/browse/JDBC (although some discussion
> about things would be welcome first)
>
> I have created a mailing list specific to clojure.java.jdbc in case
> folks want to get into deep discussions and don't want to clog up this
> main Clojure mailing list (since I understand the user base for
> java.jdbc is relatively small compared to the overall Clojure
> community): https://groups.google.com/d/forum/clojure-java-jdbc
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
