Re: [ANN] java.jdbc 0.3.0-alpha1
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.comjavascript:
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
Re: [ANN] java.jdbc 0.3.0-alpha1
Hi Sean Matching Socks,
first off, I like the new API design. Here are my questions and
suggestions:
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).
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 -. That would be
more consistent with the Clojure defaults of naming keywords at
the expense of maybe performance. I use this naming strategy for
example, because I don't want to constantly remember which keys
in my maps use the Clojure and which the database convention.
Would this be an option for 0.3.0?
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?
{:product :postgresql
:server-name example.com
:server-port 5432
:username tiger
:password scotch
:db my_db
}
Othwerwise thanks for your work on clojure.java.jdbc,
Roman.
--
--
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.
Re: [ANN] java.jdbc 0.3.0-alpha1
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.
Re: [ANN] java.jdbc 0.3.0-alpha1
Could the entities and identifiers functions (translating map-keys to SQL-names and back) be specified along with connection parameters to avoid repetition with each operation? -- -- 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.
Re: [ANN] java.jdbc 0.3.0-alpha1
Only identifiers (converting from SQL entities to Clojure keywords)
are handled in java.jdbc directly (inside result-set-seq) - entities
are handled in the DSL which generates SQL and therefore it's not
related to a connection. If you don't use the DSL, there's no
translation going on - you pass in strings to the java.jdbc functions
and they do whatever you've told them to do...
In (query db-spec (select * :employee (where {:department IT}))) the
DSL is invoked first to generate SELECT * FROM employee WHERE
department = ? before query is introduced and before db-spec is
looked at.
True, you could still have a default for identifiers on db-spec which
was used for result-set-seq but that seems asymmetric. If folks think
that's worthwhile despite the asymmetry, can someone create a ticket
in JIRA so I don't forget to look into it in more detail?
Sean
On Mon, Apr 8, 2013 at 7:24 PM, Matching Socks phill.w...@gmail.com wrote:
Could the entities and identifiers functions (translating map-keys to
SQL-names and back) be specified along with connection parameters to avoid
repetition with each operation?
--
--
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.
--
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.
