[ANN]: clj.jdbc 0.1-beta1 - Alternative implementation of jdbc wrapper for clojure.

[Andrey Antukh]

Hi!

I have some frustration with current official jdbc wrapper for clojure and I have worked in one alternative mainly because of:

- Lack of documentation.

- Philosophical differences of how things should be done.

Documentation page: http://cljjdbc.readthedocs.org/en/latest/

Github: https://github.com/niwibe/clj.jdbc

Any feedback always welcome.

Andrey

--
Andrey Antukh - Андрей Антух - <ni...@niwi.be>
http://www.niwi.be/about.html
http://www.kaleidos.net/A5694F/

"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"

[Michael Klishin]

2013/11/16 Andrey Antukh <ni...@niwi.be>

- Lack of documentation.

- Philosophical differences of how things should be done.

Documentation page: http://cljjdbc.readthedocs.org/en/latest/

+ ridiculous Clojure CA that keeps non-North America/EU contributors away.

Good job, Andrey. It's important to have more than 1 option for every problem
and clojure.java.jdbc could certainly use  some well documented, contributor friendly competition.

--
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

[Brian Craft]

On Saturday, November 16, 2013 5:11:05 AM UTC-8, Michael Klishin wrote:

+ ridiculous Clojure CA that keeps non-North America/EU contributors away.

What is this? A link will do, if this has been discussed previously. 

[Michael Klishin]

2013/11/16 Brian Craft <craft...@gmail.com>

What is this? A link will do, if this has been discussed previously. 

https://groups.google.com/forum/#!searchin/clojure/CA$20/clojure/FlwqULYM7n0/x1-ArtQe1isJ
https://groups.google.com/d/topic/clojure/0gwjKtatf-0/discussion

[Michael Klishin]

2013/11/16 Andrey Antukh <ni...@niwi.be>

- Lack of documentation.

FTR, there is some documentation for java.jdbc, but it certainly

isn't being actively worked on (despite not being covered by the CA) and may

already be out of date.

http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html

If you'd like to contribute:
http://github.com/clojuredocs/guides

[Andrey Antukh]

2013/11/16 Michael Klishin <michael....@gmail.com>

2013/11/16 Andrey Antukh <ni...@niwi.be>

- Lack of documentation.

FTR, there is some documentation for java.jdbc, but it certainly

isn't being actively worked on (despite not being covered by the CA) and may

already be out of date.

http://clojure-doc.org/articles/ecosystem/java_jdbc/home.html

Thanks! I know about existence of it! Is totally outdated with current version of java.jdbc and incomplete ;)

Andrey

[Zach Oakes]

Andrey, this looks interesting. It seems to be based on a really old version of clojure.java.jdbc, though. Is there a reason for this? Since it is a fork, it seems like it would be best to base it on a recent version, to aid those who may want to try switching to it. Also, does it require JDK 7 to compile?

[Andrey Antukh]

Hi Zach!

It is not based on any concrete version (is not a fork). Casually, it has similarities with java.jdbc 0.2.x because uses same name for some functions

(in my opinion 0.2 version has better api than 0.3). Additionally I have copied some useful functions like parsing dbspec to URI or a map of protocol->cases 

and the rest are written from scratch.

Furthermore, a new version of java.jdbc (0.3.x), introduces a lot of complexity to code in comparison to 0.2 and base it on the new version would be a mistake. 

In any case, as I said previously, clj.jdbc is not based in any concrete version of java.jdbc.

You can read more about it on faq section of clj.jdbc http://cljjdbc.readthedocs.org/en/latest/faq.html#why-one-other-jdbc-wrapper that explains a main differences

with a current version of java.jdbc (0.3)

In respect to jdk7, personally I don't know if clj.jdbc works with jdk6 because I only working with jdk7. But, any compatibility fixes for jdk6 are welcome!

2013/11/17 Zach Oakes <zso...@gmail.com>

[Sean Corfield]

To Michael: It is fairly up to date - there have only been a few small
changes to java.jdbc since the last updates to that part of
clojure-doc.org. Now that java.jdbc 0.3.0 has hit beta and has a
stable API for release, I feel more comfortable about updating the
clojure-doc.org pages to include the handful of changes that are
missing. It has been expanded quite a bit from the original version
that was part of the clojure.java.jdbc repo.

I'm a little disappointed that after moving it to clojure-doc.org
specifically to remove the CA barrier to entry, none of java.jdbc's
users have taken the time to provide updates to the documentation
site. The whole point of moving it to clojure-doc.org was to enable
community contribution.

To Andrey: I'm a bit disappointed you didn't offer to contribute to
java.jdbc's documentation since you found it lacking, and that you
didn't raise your concerns about either the documentation or the API
with me, rather than creating your own library based on the old API.
Open source projects improve through collaboration.

That said, there's always room for more libraries and alternative
approaches. I'll be a lot happier with java.jdbc when I'm able to
strip the old API out after it has been deprecated for a few releases
- and I'll point out that the API changes from 0.2.x to 0.3.0 are
primarily in response to feedback from Clojure/core. java.jdbc is in
fairly heavy production use these days so I'm having to be more
conservative about changing it than I would if it were just "my"
project and not a Clojure contrib library :)

Sean

> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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+u...@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)

[Sean Corfield]

On Sun, Nov 17, 2013 at 1:57 AM, Andrey Antukh <ni...@niwi.be> wrote:
> Additionally I have
> copied some useful functions like parsing dbspec to URI or a map of
> protocol->cases
> and the rest are written from scratch.

Looking through the source code, there are quite a few functions
copied directly from parts of java.jdbc - even maintaining docstrings,
making it clear you copied and pasted them - but I notice that you
have not maintained the copyright or license from java.jdbc.

Would you like to explain why you have copied open source software
without respecting the license and contributors?

[gaz jones]

"Because there is no patch for human stupidity"?

[Softaddicts]

You have the typical profile of people who do not understand open source.
To you, open source is the same thing has a side hobby, ...
with lack of commitment and seriousness.

How do you expect open source software quality to improve if each of us
starts to spin off our own flavor of the same lib ?
How is this a constructive cooperating effort ?
How can open source software be used in production in this context ?

Some people are using this stuff to build serious solutions to hard problems.

I will not even rant about copying without the copyright.

It's the overall lack of logic and self centric egoism that you exhibit that makes
me rant.

You should apply the maxim you have thrown in this thread to yourself.
You are much more representative of it than anyone else I saw
on this mailing list in 5 years.

Punk.

Luc P.

--
Softaddicts<lprefo...@softaddicts.ca> sent by ibisMail from my ipad!

[Andrey Antukh]

Hi Sean.

2013/11/19 Sean Corfield <seanco...@gmail.com>

I have not  proposed the api changes because java.jdbc 0.3 is ready to be released and the probability of include a significant change in the near future, it was very remote. 

And I was pretty frustrated with the current implementation.

Also, I did not want start documenting a library that I do not like how it behaves. 

On the other hand, if the situation is different, I would love to collaborate and join forces in a single library.

About license question: if these functions had not copied, but written from scratch, them would be the same functions with minimal differences or none... 

You're totally right in that would be nice to put in the documentation that is based in parts of clojure.java.jdbc and I will gladly put it. 

;)

Andrey

[Softaddicts]

Gaz, excuse me if I misunderstood you, I reread your reply and it was not clear
to me to whom you were referring in your comment.

I still stand by what I said toward the op. Saying that if rewritten the code
would be the same as the original is a lame excuse, it's the same as all that
internet cheating thing in schools. Unexcusable.

Luc P.

[Michael Klishin]

2013/11/20 Softaddicts <lprefo...@softaddicts.ca>

How do you expect open source software quality to improve if each of us
starts to spin off our own flavor of the same lib ?

Sometimes creating a new library is the right thing to do.

I'll give you one example.

When I started Langohr and Monger in 2011, there were WabbitMQ and congomongo.

I could have contributed to both but what I wanted those clients to be was quite far away from
their established public API's. In other words, I could improve them only up to a point and

probably fail at that since I'm not great at convincing other people their API's need to seriously
change. So I did my own thing, which does exactly what I wanted developed and documented
up to my standards. Some developers apparently like them, too.

In clojure.java.jdbc's case, the development process is just too slow. If you want to contribute
anything substantial or incompatible or simply opinionated, chances are, you will have to waste

*many* months convincing people, running after people to screen your patches, etc.

Or you can take another route: write code, document it, promote your library, without waiting
for anybody. And get a great feedback loop for yourself and the rest of the community.

Needless to say, if you reuse some code from the original project you should respect the license
in give credit when its due. In Monger's case, we've borrowed one function which was subsequently

slightly modified and we still have a mention for that [1].

1. https://github.com/michaelklishin/monger/blob/master/src/clojure/monger/conversion.clj#L1-3

[Michael Klishin]

2013/11/20 Andrey Antukh <ni...@niwi.be>

About license question: if these functions had not copied, but written from scratch, them would be the same functions with minimal differences or none... 

Sorry but that's a ridiculous argument. You must respect and obey by the license of the project you take code
from.

[gaz jones]

Whoops, sorry looks like my intended light-hearted sarcasm based on one of the email signatures in the thread got mis-interpreted. Hard to express in an email, perhaps a cheeky :P after would have let you know I wasn't being particularly serious!

No offense intended, or taken :)

[Andrey Antukh]

Is not an excuse, is only a opinion, nothing more. This opinion can not change that, mention the original author is right and I've done it. I have no way intend to belittle anyone.

;)

Andrey

2013/11/19 Softaddicts <lprefo...@softaddicts.ca>

--

Andrey Antukh - Андрей Антух - <ni...@niwi.be>
http://www.niwi.be/about.html
http://www.kaleidos.net/A5694F/

"Linux is for people who hate Windows, BSD is for people who love UNIX"

"Social Engineer -> Because there is no patch for human stupidity"

[Alexander Hudek]

Sean, for what it's worth many of us do appreciate the slow and careful development of java.jdbc. When it's used so widely in production code frequent breaking changes are very costly. The new 0.3.0 API is pretty nice, though I have found documentation for it somewhat lacking. That said, I haven't found time to contribute to it either.

Perhaps this thread isn't the right place, but I am curious about the rational and plans for the sql namespace. Is this going to be fleshed out to be more fully featured over time? Why choose to integrate it rather than have it as a separate add-on? 

Thanks for the work on jdbc. :-)

Alex

[Sean Corfield]

I'll address the java.jdbc.sql question in a separate thread (I've
actually addressed it before so I'll search the archives and elaborate
on my previous responses). Give me an hour or so...

[Sean Corfield]

On Tue, Nov 19, 2013 at 2:28 PM, Michael Klishin
<michael....@gmail.com> wrote:
> 2013/11/20 Andrey Antukh <ni...@niwi.be>
>> About license question: if these functions had not copied, but written
>> from scratch, them would be the same functions with minimal differences or
>> none...
> Sorry but that's a ridiculous argument. You must respect and obey by the
> license of the project you take code
> from.

Thank you Michael.

Any company that uses Andrey's library at this point is immediately in
a difficult position from a legal standpoint...

[Andrey Antukh]

Hi agai Soan.

Repeating now: as I said previously, copyright notice of taken code should to be present. And is my mistake from the start not incluide it, I don't have any problem for it. Now I have added a copyright notice.

Yo can explain me that is a current legal problem has my library. I would fix it.

We are all human here, and we make mistakes. It would be better to help fix it instead attempts to discredit...

Andrey.

Sent from my Nexus 4

[Andy Fingerhut]

Andrey:

I am no lawyer, but the following answer on this Q&A page about the Eclipse Public License suggests that if you take code from an EPL-licensed project (which java.jdbc is), then the project in which you include it must also be licensed under the EPL (whch clj.jdbc is currently not, as far as I can tell):

    http://www.eclipse.org/legal/eplfaq.php#USEINANOTHER

Andy

[Andrey Antukh]

Hi Andy.

A lot of thanks for this information. I was also researching on this point.

Currently I have removed all taken code from the clojure.java.jdbc, license problem should be solved.

Again, I in no way want to belittle the original work. It was big mistake on my part not to mention from start of the project.

Andrey

2013/11/20 Andy Fingerhut <andy.fi...@gmail.com>

--

[Lars Rune Nøstdal]

Looks interesting. It even has the issue tracker on github still enabled.

[Sean Corfield]

On Fri, Nov 29, 2013 at 3:38 AM, Lars Rune Nøstdal
<larsn...@gmail.com> wrote:
> Looks interesting. It even has the issue tracker on github still enabled.

The reason contrib libraries (and Clojure itself) have the issue
tracker disabled on Github is because they use JIRA for tracking
issues - and pull requests are not accepted for contrib libraries (or
Clojure itself), instead you need to submit a patch to a ticket in
JIRA (and you need a signed Contributor's Agreement on file). Please
don't revisit that discussion tho' - search the archives for several
of the (often heated) discussions about patches vs pull requests, and
just accept that's the way things are done for Clojure and its contrib
libraries...