Uh, no. On Postgres's own web site they link to a site showing a 42.7% level of compliance for Postgres 7.2 with the JDBC 2.0 API. While I'm not sure how important all these issues are, this level is not what I would call "good", let alone "great" and you don't have to get too intensively into it to find things that are missing.
I would be interested in knowing what the level of compliance with 7.3 is.
Better cursor support in JDBC bindings (and presumably other language interfaces). Right now, executing a query fetches the entire results to memory. That doesn't scale of course. But I hope to see this change soon.
This is the one that bit me in the butt last week. A very large result set caused OutOfMemoryExceptions. setFetchSize() wasn't implemented. I got around it by using the handy but non-standard LIMIT-OFFSET syntax, but this is subpar, IMHO. I'd be very interested in this enhancement.
I don't think your example is a clearcut win for simple properties files. It sure won't scale.
suppose you have several servers to describe. Now your simple properties file has become a lot less simple. Notice how clumsy the comma notation becomes as compared to the nested-element notation.
Sorry, the more complex it gets, the better the xml version starts to look. It lets you see grouping and inclusion, much better than the properties file notation does.
>>Ant a positive example of where the true goals of open source have succeeded.
Right you are!
And I especially like the way they have managed to include not only "Open Source heroes" who read the developer mailing list religiously and know every corner of the project, but also the occasional contributor such as myself, who needed something on one of the "optional tasks" and took the bull by the horns.
Besides all the other things that the people above me have said, here's another:
As an open-source and relatively young open-source project, and had and still does have some rough edges. However, in the two years I've been using it and in the one year since I've been contributing to it, many parts that sucked now suck less or don't suck at all.
As to my contributions, they have been to the StarTeam optional task. StarTeam is a proprietary revision control system. This is another advantage of ant. Yes, I could have used make, or ant as well, to simply exec the rather ugly command line tools provided by StarTeam - but ST also provides a java api that is much friendlier to work with and also lets you do a couple of things the command line tools don't. That is something I wouldn't know how to interface to with make.
That said, I don't know if these considerations are worth your considerable investment in learning make, but one can always try. At one time I had a considerable investment in make too.
I am an occasional contributor to Ant and therefore, I suppose, an advanced user, and I found the book well worth purchasing.
Sure, you can learn the basics in an hour, and look at the docs to go deeper, but you miss stuff. Maybe you don't find the BEST way to solve your problem, you stop at the first hack that gets the job done. Somewhere down the line, as your project gets more complicated, you pay something for that approach. Eventually, you may want to tie up your random knowledge a little neater and move to the next level of understanding.
Not only that, but since Ant is an open source project, it is changing, and if your old stuff still works, maybe you won't notice the new stuff and continue to use methods that once were state of the art but are now inferior.
It all depends on your use patterns.
So it was with me. I just purchased the book and it has been worth the money I paid for it. I find that the best time to buy such a book is AFTER I have learned the basics, when I want to take my knowledge to the next level. There are many techniques for scaling ant to work with larger projects, for combining scripts so that they work both standalone and separately and all of these are touched on in the book (not as much as I would have liked, but they got me off the dime).
I do at least glance at the beginner chapters too. There are always one or two techniques, maybe new ones, that I missed. So a book like this lets you backfill your knowledge.
Of course there are a lot of books out there that are crap. This is not one of them. These authors did a great job.
Slashdot Mirror
I would be interested in knowing what the level of compliance with 7.3 is.
I would call the JDBC support in 7.2 "adequate".
Better cursor support in JDBC bindings (and presumably other language interfaces). Right now, executing a query fetches the entire results to memory. That doesn't scale of course. But I hope to see this change soon. This is the one that bit me in the butt last week. A very large result set caused OutOfMemoryExceptions. setFetchSize() wasn't implemented. I got around it by using the handy but non-standard LIMIT-OFFSET syntax, but this is subpar, IMHO. I'd be very interested in this enhancement.
I don't think your example is a clearcut win for simple properties files. It sure won't scale.
v er1.Protocol=httpl ,three.html ...
server20.Protocol=httpf ive.html,six.html,seven. html,eight.html,isnt.this.line.getting.a.little.lo ng.html,html.html,etc.
suppose you have several servers to describe. Now your simple properties file has become a lot less simple. Notice how clumsy the comma notation becomes as compared to the nested-element notation.
server1.host=myhost.com
server1.Port=7876
ser
server1.Files=one.html,two.htm
server20.host=yourhost.com
server20.Port=7877
server20.Files=four.html,
Sorry, the more complex it gets, the better the xml version starts to look. It lets you see grouping and inclusion, much better than the properties file notation does.
>>Ant a positive example of where the true goals of open source have succeeded.
Right you are!
And I especially like the way they have managed to include not only "Open Source heroes" who read the developer mailing list religiously and know every corner of the project, but also the occasional contributor such as myself, who needed something on one of the "optional tasks" and took the bull by the horns.
Besides all the other things that the people above me have said, here's another: As an open-source and relatively young open-source project, and had and still does have some rough edges. However, in the two years I've been using it and in the one year since I've been contributing to it, many parts that sucked now suck less or don't suck at all. As to my contributions, they have been to the StarTeam optional task. StarTeam is a proprietary revision control system. This is another advantage of ant. Yes, I could have used make, or ant as well, to simply exec the rather ugly command line tools provided by StarTeam - but ST also provides a java api that is much friendlier to work with and also lets you do a couple of things the command line tools don't. That is something I wouldn't know how to interface to with make. That said, I don't know if these considerations are worth your considerable investment in learning make, but one can always try. At one time I had a considerable investment in make too.
I am an occasional contributor to Ant and therefore, I suppose, an advanced user, and I found the book well worth purchasing.
Sure, you can learn the basics in an hour, and look at the docs to go deeper, but you miss stuff. Maybe you don't find the BEST way to solve your problem, you stop at the first hack that gets the job done. Somewhere down the line, as your project gets more complicated, you pay something for that approach. Eventually, you may want to tie up your random knowledge a little neater and move to the next level of understanding.
Not only that, but since Ant is an open source project, it is changing, and if your old stuff still works, maybe you won't notice the new stuff and continue to use methods that once were state of the art but are now inferior.
It all depends on your use patterns.
So it was with me. I just purchased the book and it has been worth the money I paid for it. I find that the best time to buy such a book is AFTER I have learned the basics, when I want to take my knowledge to the next level. There are many techniques for scaling ant to work with larger projects, for combining scripts so that they work both standalone and separately and all of these are touched on in the book (not as much as I would have liked, but they got me off the dime).
I do at least glance at the beginner chapters too. There are always one or two techniques, maybe new ones, that I missed. So a book like this lets you backfill your knowledge.
Of course there are a lot of books out there that are crap. This is not one of them. These authors did a great job.
Steve Cohen
All depends how you set it up. There are problems with ant, but for us, this is not one of them.