On Tue, Apr 9, 2013 at 1:49 PM, r0man <roman.sche...@burningswell.com> 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.


Reply via email to