Re: svn commit: r787914 - in /couchdb/trunk: ./ src/couchdb/ test/etap/
I totally forgot to give the apropriate kudos to Bob Dionne for all
the help he's been giving me on getting tests written. He's blazing
alot of the trail in writing these new tests while I try and keep up.
Paul Davis
On Wed, Jun 24, 2009 at 1:51 AM, wrote:
> Author: davisp
> Date: Wed Jun 24 05:51:41 2009
> New Revision: 787914
>
> URL: http://svn.apache.org/viewvc?rev=787914&view=rev
> Log:
> Lots of tests for couch_config.erl
> Refactored couch_config.erl to resolve COUCHDB-384
> Tweaked the main Makefile.am to make the cover and check targets depend on
> the dev target instead of the all target.
> Added the executable property to all test files to make them easily runnable
> as standalone tests (as in not via prove).
>
>
> Added:
> couchdb/trunk/test/etap/080-config-get-set.t (with props)
> couchdb/trunk/test/etap/081-config-override.1.ini
> couchdb/trunk/test/etap/081-config-override.2.ini
> couchdb/trunk/test/etap/081-config-override.t (with props)
> couchdb/trunk/test/etap/082-config-register.t (with props)
> couchdb/trunk/test/etap/083-config-no-files.t (with props)
> Modified:
> couchdb/trunk/Makefile.am
> couchdb/trunk/src/couchdb/couch_config.erl
> couchdb/trunk/test/etap/031-doc-to-json.t
> couchdb/trunk/test/etap/040-util.t (props changed)
> couchdb/trunk/test/etap/050-stream.t (contents, props changed)
> couchdb/trunk/test/etap/060-kt-merging.t (props changed)
> couchdb/trunk/test/etap/061-kt-missing-leaves.t (props changed)
> couchdb/trunk/test/etap/062-kt-remove-leaves.t (props changed)
> couchdb/trunk/test/etap/063-kt-get-leaves.t (props changed)
> couchdb/trunk/test/etap/064-kt-counting.t (props changed)
> couchdb/trunk/test/etap/065-kt-stemming.t (props changed)
> couchdb/trunk/test/etap/070-couch-db.t (props changed)
>
> Modified: couchdb/trunk/Makefile.am
> URL:
> http://svn.apache.org/viewvc/couchdb/trunk/Makefile.am?rev=787914&r1=787913&r2=787914&view=diff
> ==
> --- couchdb/trunk/Makefile.am (original)
> +++ couchdb/trunk/Makefile.am Wed Jun 24 05:51:41 2009
> @@ -36,10 +36,10 @@
> THANKS.gz: $(top_srcdir)/THANKS
> -gzip -9 < $< > $@
>
> -check: all
> +check: dev
> prove test/etap/*.t
>
> -cover: all
> +cover: dev
> rm -f cover/*.coverdata
> COVER=1 COVER_BIN=./src/couchdb/ prove test/etap/*.t
> SRC=./src/couchdb/ \
>
> Modified: couchdb/trunk/src/couchdb/couch_config.erl
> URL:
> http://svn.apache.org/viewvc/couchdb/trunk/src/couchdb/couch_config.erl?rev=787914&r1=787913&r2=787914&view=diff
> ==
> --- couchdb/trunk/src/couchdb/couch_config.erl (original)
> +++ couchdb/trunk/src/couchdb/couch_config.erl Wed Jun 24 05:51:41 2009
> @@ -10,42 +10,47 @@
> % License for the specific language governing permissions and limitations
> under
> % the License.
>
> -%% @doc Reads CouchDB's ini file and gets queried for configuration
> parameters.
> -%% This module is initialized with a list of ini files that it
> -%% consecutively reads Key/Value pairs from and saves them in an ets
> -%% table. If more an one ini file is specified, the last one is used to
> -%% write changes that are made with store/2 back to that ini file.
> +% Reads CouchDB's ini file and gets queried for configuration parameters.
> +% This module is initialized with a list of ini files that it consecutively
> +% reads Key/Value pairs from and saves them in an ets table. If more an one
> +% ini file is specified, the last one is used to write changes that are made
> +% with store/2 back to that ini file.
>
> -module(couch_config).
> +-behaviour(gen_server).
> +
> -include("couch_db.hrl").
>
> --behaviour(gen_server).
> --export([start_link/1, init/1, handle_call/3, handle_cast/2, handle_info/2,
> - terminate/2, code_change/3]).
> --export([all/0, get/1, get/2, get/3, delete/2, set/3, set/4, register/1,
> - register/2, load_ini_file/1]).
> -
> --record(config,
> - {notify_funs=[],
> - write_filename=""
> - }).
>
> -%% Public API %%
> +-export([start_link/1, stop/0]).
> +-export([all/0, get/1, get/2, get/3, set/3, set/4, delete/2, delete/3]).
> +-export([register/1, register/2]).
> +-export([parse_ini_file/1]).
> +
> +-export([init/1, terminate/2, code_change/3]).
> +-export([handle_call/3, handle_cast/2, handle_info/2]).
> +
> +-record(config, {
> + notify_funs=[],
> + write_filename=undefined
> +}).
>
> -%% @type etstable() = integer().
>
> start_link(IniFiles) ->
> gen_server:start_link({local, ?MODULE}, ?MODULE, IniFiles, []).
>
> +stop() ->
> + gen_server:cast(?MODULE, stop).
> +
> +
> all() ->
> - lists:sort(ets:tab2list(?MODULE)).
> + lists:sort(gen_server:call(?MODULE, all)).
> +
>
> get(Section) when is_binary(Section) ->
> ?MODULE:get(?b2l(Section));
> get(Section) ->
> -
[jira] Resolved: (COUCHDB-384) [PATCH] Improvements to couch_config for unit testing purposes
[ https://issues.apache.org/jira/browse/COUCHDB-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Joseph Davis resolved COUCHDB-384. --- Resolution: Fixed Fix Version/s: 0.10 Assignee: Paul Joseph Davis Fixed in r787914. > [PATCH] Improvements to couch_config for unit testing purposes > -- > > Key: COUCHDB-384 > URL: https://issues.apache.org/jira/browse/COUCHDB-384 > Project: CouchDB > Issue Type: Improvement > Components: Database Core >Affects Versions: 0.9 >Reporter: Brad Anderson >Assignee: Paul Joseph Davis >Priority: Minor > Fix For: 0.10 > > Attachments: couchdb-384.patch > > > To be able to run unit tests involving configuration (i.e. couch_config > module), two changes are proposed: > 1. The ability to start the couch_config gen_server with no .ini files in > start_link/1. This means that CouchDB doesn't even need to be running for > tests to be performed. The caller of set/4 needs to use 'false' as the > Persist argument, but this is probably desirable when running unit tests. > 2. The ability to shut down the couch_config gen_server is necessary for > proper cleanup after the tests are run. > The attached patch solves both issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: "Personal" Couch DB.
Nothing quite like that and there are a few different prevailing ideas. For instant gratification on OS X though you can check out CouchDBX. Jon Gretar's got a version on github that just sits in the sys tray out of the way. While not SQLite per se, it does allow instant end user access to a locally running CouchDB. There's effort to get a windows installer afoot as well. There are technical hurdles still being navigated though so no ETA. As for other *nix systems I'm not sure on what options there are for easily running CouchDB as a single user. There was a guy in #couchdb asking just today about binding to a kernel provided port that would probably be on the agenda. Paul Davis On Tue, Jun 23, 2009 at 10:17 PM, Dale Wiles wrote: > I've been following CouchDB for a while and I'm really impressed with the way > it's coming along. > > However, like >90% of the users out there, I'm not a business and I don't > really care about replication and daemons and scary things that go bump in > the kernel. I just need somewhere to put my address lists and record > collection. > > Are there any plans, or is it even feasible, to make a serverless version of > CouchDB, in a manor similar to SqLite? > > For those who don't know SqLite: CouchDB would be a file or set of files. It > "starts up" when the file is opened and "shuts down" when the file closes. > If you can read the file you can read the DB. If you can write the file, you > an write the DB. Database locking is handled by the DB. > > I think a *lot* of potential casual database users would be interested in a > no hassle/no mystery version of CouchDB they could play with. It's something > to think about. > > - Dale > > -- > Dale Wiles > dale.wi...@gmail.com >
"Personal" Couch DB.
I've been following CouchDB for a while and I'm really impressed with the way it's coming along. However, like >90% of the users out there, I'm not a business and I don't really care about replication and daemons and scary things that go bump in the kernel. I just need somewhere to put my address lists and record collection. Are there any plans, or is it even feasible, to make a serverless version of CouchDB, in a manor similar to SqLite? For those who don't know SqLite: CouchDB would be a file or set of files. It "starts up" when the file is opened and "shuts down" when the file closes. If you can read the file you can read the DB. If you can write the file, you an write the DB. Database locking is handled by the DB. I think a *lot* of potential casual database users would be interested in a no hassle/no mystery version of CouchDB they could play with. It's something to think about. - Dale -- Dale Wiles dale.wi...@gmail.com pgp4EL2rbHrjN.pgp Description: PGP signature
Re: Unicode normalization (was Re: The 1.0 Thread)
On 24/06/2009, at 1:57 AM, Paul Davis wrote: Are there byte order semantics for UTF-8? No, UTF-8 is independent of byte ordering because it's a byte stream. Or other cases where sorting by UTF-8 binary representation is going to cause issues? Remember that the end goal is to create deterministic serializations for hashing. Sorting over the UTF-8 bytes is fine for this. Sorting by code point doesn't seem like it'd get us anything other than added complexity. Agreed, because you would have to deal with surrogates in UTF-16. Patches welcome. Of course. Let me qualify by saying I have no time to do this, I'm merely taking part in a discussion. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 When I hear somebody sigh, 'Life is hard,' I am always tempted to ask, 'Compared to what?' -- Sydney Harris
Re: Unicode normalization (was Re: The 1.0 Thread)
On 24/06/2009, at 1:57 AM, Paul Davis wrote: Are there byte order semantics for UTF-8? No, UTF-8 is independent of byte ordering because it's a byte stream. Or other cases where sorting by UTF-8 binary representation is going to cause issues? Remember that the end goal is to create deterministic serializations for hashing. Sorting over the UTF-8 bytes is fine for this. Sorting by code point doesn't seem like it'd get us anything other than added complexity. Agreed, because you would have to deal with surrogates in UTF-16. Patches welcome. Of course. Let me qualify by saying I have no time to do this, I'm merely taking part in a discussion. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 When I hear somebody sigh, 'Life is hard,' I am always tempted to ask, 'Compared to what?' -- Sydney Harris
[jira] Commented: (COUCHDB-393) Cannot discover currently running http port if ini file specifies port 0
[ https://issues.apache.org/jira/browse/COUCHDB-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723185#action_12723185 ] Noah Slater commented on COUCHDB-393: - I think Paul Davis hit on the best option here. It would be nice to hook "couchdb -s" into some kind of Erlang VM communication, and we could return the IP address and port number on the command line in some parseable fashion. Perhaps something similar to "Visit the Futon administration console at http://0.0.0.0:0/_utils/"; like we used to show on CouchDB start-up. > Cannot discover currently running http port if ini file specifies port 0 > > > Key: COUCHDB-393 > URL: https://issues.apache.org/jira/browse/COUCHDB-393 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 0.9 > Environment: Ubuntu 9.04 >Reporter: Stuart Langridge > > It is currently not possible, if the ini file specifies port 0 as the http > port (so that the OS chooses a random port) to discover which port the OS > actually chose. > It would be nice if the currently running port was made available in the > statusline output (couchdb -s), but a log statement would be adequate; some > way that an external script can discover which port a running CouchDB is > listening on. > Edited discussion from #couchdb: > aquarius: well at a glance it appears couch_http passes the 0 to > mochiweb_http which passes it to the mochiweb_socket_server, which passes it > to gen_tcp, an erlang module that lets the underlying OS assign it. > mochiweb_socket_server then grabs that port and stores it. It has a get > method to retrieve properties but that needs to be exposed to mochiweb_http > so it would take a little work to do it. It's probably a JIRA ticket, unless > someone else sees a quicker approach > bitdiddle: you got that far and didn't find it? > davisp: is there a better way to find the port? > oh, is that not the bind port? > I was just thinking a log statement > davisp: the problem is if you specify 0 as the bind port (so the > OS chooses a port), how do you find out what was chosen? > aquarius: you have to look at the port returned by the socket > aquarius: in other words, CouchDB was never written to do that > AFAIK > davisp: I found it, just needs some work to expose it > aquarius: and by do that, I mean, we never put in a statement to log > that > mochiweb_http is the module that needs to bubble it up > davisp: I don't really mind whether it's a log statement or it's > exposed to couchdb -s (the latter seems tidier to me, but whichever), I just > want to be able to start couch on port 0 and then later find out which port > got chosen :) > aquarius: for the time being you can use something like netstat or > lsof, but we'll get a log statement in there or something -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Unicode normalization (was Re: The 1.0 Thread)
On Wed, Jun 24, 2009 at 12:45:58AM +0930, Antony Blakey wrote: > Having said that, IMO it would be a good i18n feature to be able set the > locale of a database, maybe even at the granularity of a view, defaulting to > the database's locale. The key ordering should respect that locale. An option > to normalize keys would also be a good idea. The reason for setting a locale > at the view level is that it might be useful to create multiple views with > different locales, to present different localized result orderings to end > users. One immediate issue is that the local would have to be injected into > view servers to prevent possible weirdness. +1 on all of this. -- Noah Slater, http://tumbolia.org/nslater
Re: Unicode normalization (was Re: The 1.0 Thread)
On Tue, Jun 23, 2009 at 09:26:23AM +0100, Brian Candler wrote: > As an aside: I support that subtly different encodings of the "same" > document (according to NFC) should have different revs, because (a) it's > unlikely that multiple different client implementations will be making the > same changes to the same documents (i.e. the clients in a cluster are likely > to be homogeneous), and (b) such conflicts are easy to resolve anyway. Clients on the Web are anything but homogeneous! -- Noah Slater, http://tumbolia.org/nslater
Re: Unicode normalization (was Re: The 1.0 Thread)
On Tue, Jun 23, 2009 at 11:15 AM, Antony Blakey wrote: > > On 23/06/2009, at 11:43 PM, Paul Davis wrote: > >> Interesting point. I take this as a pretty clear reason for discarding >> UCA for member ordering. Normalization isn't affected by locale right? >> I haven't seen anything to suggest as such so I assume not. > > IIUC each normalization form is strictly functional. > > IMO, given that ICU provides normalization functions, CouchDB should use > them in this case, exposing the canonicalisation transformation, and a > shortcut producing the hash, as a client-accessible endpoint. I say this > from a 'why not do it right?' perspective. > Regardless of whether normalization is included in the deterministic revision algorithm I think that normalization end points, or perhaps query string parameters for performing normalization on incoming data would be a good thing. I reject the assertion that this is a question of right or wrong. I see valid arguments for and against including normalization as part of the deterministic revision algorithm. Considering a query parameter to process incoming data conditionally I'm leaning towards not including it, but I'm always open to being convinced otherwise. > Member ordering could be binary, over either the code points (e.g. 32 bits) > or the bytes of the UTF-8 representation. Given the ease of creating a UTF-8 > iterator that is probably best. UTF-16 is the most common native encoding, > but you don't want to do a byte-level collation over a UTF-16/32 encoding > because the result is dependent on byte ordering. > Are there byte order semantics for UTF-8? Or other cases where sorting by UTF-8 binary representation is going to cause issues? Remember that the end goal is to create deterministic serializations for hashing. Sorting by code point doesn't seem like it'd get us anything other than added complexity. > The problem with this is that the canonical form might look bizarre for a > non-ASCII document, but a canonical collation is by definition always going > to look wrong to someone. For the current use, as an intermediate form > destined only for hashing, this doesn't matter anyway. > Yep. > Having said that, IMO it would be a good i18n feature to be able set the > locale of a database, maybe even at the granularity of a view, defaulting to > the database's locale. The key ordering should respect that locale. An > option to normalize keys would also be a good idea. The reason for setting a > locale at the view level is that it might be useful to create multiple views > with different locales, to present different localized result orderings to > end users. One immediate issue is that the local would have to be injected > into view servers to prevent possible weirdness. > > I think it's easier and better to do these kind of things on the server > because you know you have the facilities to do it there (e.g. ICU), whereas > making it a client issue impedes use of the data by different clients. > Patches welcome. Paul Davis > Antony Blakey > - > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > On the other side, you have the customer and/or user, and they tend to do > what we call "automating the pain." They say, "What is it we're doing now? > How would that look if we automated it?" Whereas, what the design process > should properly be is one of saying, "What are the goals we're trying to > accomplish and how can we get rid of all this task crap?" > -- Alan Cooper > > >
[jira] Commented: (COUCHDB-393) Cannot discover currently running http port if ini file specifies port 0
[ https://issues.apache.org/jira/browse/COUCHDB-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723108#action_12723108 ] Antony Blakey commented on COUCHDB-393: --- Why not use the same mechanism as the pid file e.g. a command line option specifying a file to put write the port number to. > Cannot discover currently running http port if ini file specifies port 0 > > > Key: COUCHDB-393 > URL: https://issues.apache.org/jira/browse/COUCHDB-393 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 0.9 > Environment: Ubuntu 9.04 >Reporter: Stuart Langridge > > It is currently not possible, if the ini file specifies port 0 as the http > port (so that the OS chooses a random port) to discover which port the OS > actually chose. > It would be nice if the currently running port was made available in the > statusline output (couchdb -s), but a log statement would be adequate; some > way that an external script can discover which port a running CouchDB is > listening on. > Edited discussion from #couchdb: > aquarius: well at a glance it appears couch_http passes the 0 to > mochiweb_http which passes it to the mochiweb_socket_server, which passes it > to gen_tcp, an erlang module that lets the underlying OS assign it. > mochiweb_socket_server then grabs that port and stores it. It has a get > method to retrieve properties but that needs to be exposed to mochiweb_http > so it would take a little work to do it. It's probably a JIRA ticket, unless > someone else sees a quicker approach > bitdiddle: you got that far and didn't find it? > davisp: is there a better way to find the port? > oh, is that not the bind port? > I was just thinking a log statement > davisp: the problem is if you specify 0 as the bind port (so the > OS chooses a port), how do you find out what was chosen? > aquarius: you have to look at the port returned by the socket > aquarius: in other words, CouchDB was never written to do that > AFAIK > davisp: I found it, just needs some work to expose it > aquarius: and by do that, I mean, we never put in a statement to log > that > mochiweb_http is the module that needs to bubble it up > davisp: I don't really mind whether it's a log statement or it's > exposed to couchdb -s (the latter seems tidier to me, but whichever), I just > want to be able to start couch on port 0 and then later find out which port > got chosen :) > aquarius: for the time being you can use something like netstat or > lsof, but we'll get a log statement in there or something -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Unicode normalization (was Re: The 1.0 Thread)
On 23/06/2009, at 11:43 PM, Paul Davis wrote: Interesting point. I take this as a pretty clear reason for discarding UCA for member ordering. Normalization isn't affected by locale right? I haven't seen anything to suggest as such so I assume not. IIUC each normalization form is strictly functional. IMO, given that ICU provides normalization functions, CouchDB should use them in this case, exposing the canonicalisation transformation, and a shortcut producing the hash, as a client-accessible endpoint. I say this from a 'why not do it right?' perspective. Member ordering could be binary, over either the code points (e.g. 32 bits) or the bytes of the UTF-8 representation. Given the ease of creating a UTF-8 iterator that is probably best. UTF-16 is the most common native encoding, but you don't want to do a byte-level collation over a UTF-16/32 encoding because the result is dependent on byte ordering. The problem with this is that the canonical form might look bizarre for a non-ASCII document, but a canonical collation is by definition always going to look wrong to someone. For the current use, as an intermediate form destined only for hashing, this doesn't matter anyway. Having said that, IMO it would be a good i18n feature to be able set the locale of a database, maybe even at the granularity of a view, defaulting to the database's locale. The key ordering should respect that locale. An option to normalize keys would also be a good idea. The reason for setting a locale at the view level is that it might be useful to create multiple views with different locales, to present different localized result orderings to end users. One immediate issue is that the local would have to be injected into view servers to prevent possible weirdness. I think it's easier and better to do these kind of things on the server because you know you have the facilities to do it there (e.g. ICU), whereas making it a client issue impedes use of the data by different clients. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 On the other side, you have the customer and/or user, and they tend to do what we call "automating the pain." They say, "What is it we're doing now? How would that look if we automated it?" Whereas, what the design process should properly be is one of saying, "What are the goals we're trying to accomplish and how can we get rid of all this task crap?" -- Alan Cooper
[jira] Commented: (COUCHDB-393) Cannot discover currently running http port if ini file specifies port 0
[ https://issues.apache.org/jira/browse/COUCHDB-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723103#action_12723103 ] Paul Joseph Davis commented on COUCHDB-393: --- As was pointed out, reading the port from a log file is probably not the best solution. The other alternative would be to make it available with something like `couchdb -s` which would require some other voodoo magic. Another alternative would be to update the couchdb -s command to actually be a couchdbctl command that uses Erlang RPC similar to how rabbitmqctl works. The setup isn't without problems though as it requires coordination of erlang cookies and other bits. Any one else have thoughts on how to accomplish this better than the log style? > Cannot discover currently running http port if ini file specifies port 0 > > > Key: COUCHDB-393 > URL: https://issues.apache.org/jira/browse/COUCHDB-393 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Affects Versions: 0.9 > Environment: Ubuntu 9.04 >Reporter: Stuart Langridge > > It is currently not possible, if the ini file specifies port 0 as the http > port (so that the OS chooses a random port) to discover which port the OS > actually chose. > It would be nice if the currently running port was made available in the > statusline output (couchdb -s), but a log statement would be adequate; some > way that an external script can discover which port a running CouchDB is > listening on. > Edited discussion from #couchdb: > aquarius: well at a glance it appears couch_http passes the 0 to > mochiweb_http which passes it to the mochiweb_socket_server, which passes it > to gen_tcp, an erlang module that lets the underlying OS assign it. > mochiweb_socket_server then grabs that port and stores it. It has a get > method to retrieve properties but that needs to be exposed to mochiweb_http > so it would take a little work to do it. It's probably a JIRA ticket, unless > someone else sees a quicker approach > bitdiddle: you got that far and didn't find it? > davisp: is there a better way to find the port? > oh, is that not the bind port? > I was just thinking a log statement > davisp: the problem is if you specify 0 as the bind port (so the > OS chooses a port), how do you find out what was chosen? > aquarius: you have to look at the port returned by the socket > aquarius: in other words, CouchDB was never written to do that > AFAIK > davisp: I found it, just needs some work to expose it > aquarius: and by do that, I mean, we never put in a statement to log > that > mochiweb_http is the module that needs to bubble it up > davisp: I don't really mind whether it's a log statement or it's > exposed to couchdb -s (the latter seems tidier to me, but whichever), I just > want to be able to start couch on port 0 and then later find out which port > got chosen :) > aquarius: for the time being you can use something like netstat or > lsof, but we'll get a log statement in there or something -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-393) Cannot discover currently running http port if ini file specifies port 0
[
https://issues.apache.org/jira/browse/COUCHDB-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723097#action_12723097
]
Stuart Langridge commented on COUCHDB-393:
--
Tiny patch to write out to the logfile:
Index: mochiweb_socket_server.erl
===
--- mochiweb_socket_server.erl (revision 787671)
+++ mochiweb_socket_server.erl (working copy)
@@ -150,6 +150,7 @@
case gen_tcp:listen(Port, Opts) of
{ok, Listen} ->
{ok, ListenPort} = inet:port(Listen),
+io:format("Now listening on port ~w.~n", [ListenPort]),
{ok, new_acceptor(State#mochiweb_socket_server{listen=Listen,
port=ListenPort})};
{error, Reason} ->
> Cannot discover currently running http port if ini file specifies port 0
>
>
> Key: COUCHDB-393
> URL: https://issues.apache.org/jira/browse/COUCHDB-393
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Affects Versions: 0.9
> Environment: Ubuntu 9.04
>Reporter: Stuart Langridge
>
> It is currently not possible, if the ini file specifies port 0 as the http
> port (so that the OS chooses a random port) to discover which port the OS
> actually chose.
> It would be nice if the currently running port was made available in the
> statusline output (couchdb -s), but a log statement would be adequate; some
> way that an external script can discover which port a running CouchDB is
> listening on.
> Edited discussion from #couchdb:
> aquarius: well at a glance it appears couch_http passes the 0 to
> mochiweb_http which passes it to the mochiweb_socket_server, which passes it
> to gen_tcp, an erlang module that lets the underlying OS assign it.
> mochiweb_socket_server then grabs that port and stores it. It has a get
> method to retrieve properties but that needs to be exposed to mochiweb_http
> so it would take a little work to do it. It's probably a JIRA ticket, unless
> someone else sees a quicker approach
> bitdiddle: you got that far and didn't find it?
> davisp: is there a better way to find the port?
> oh, is that not the bind port?
> I was just thinking a log statement
> davisp: the problem is if you specify 0 as the bind port (so the
> OS chooses a port), how do you find out what was chosen?
> aquarius: you have to look at the port returned by the socket
> aquarius: in other words, CouchDB was never written to do that
> AFAIK
> davisp: I found it, just needs some work to expose it
> aquarius: and by do that, I mean, we never put in a statement to log
> that
> mochiweb_http is the module that needs to bubble it up
> davisp: I don't really mind whether it's a log statement or it's
> exposed to couchdb -s (the latter seems tidier to me, but whichever), I just
> want to be able to start couch on port 0 and then later find out which port
> got chosen :)
> aquarius: for the time being you can use something like netstat or
> lsof, but we'll get a log statement in there or something
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Unicode normalization (was Re: The 1.0 Thread)
On Tue, Jun 23, 2009 at 5:05 AM, Antony Blakey wrote: > > On 23/06/2009, at 11:22 AM, Noah Slater wrote: > >> Could Unicode normalisation affect the sorting of keys with option two? > > On a related issue: the locale certainly could e.g. it changes the collation > order of accented characters. > Interesting point. I take this as a pretty clear reason for discarding UCA for member ordering. Normalization isn't affected by locale right? I haven't seen anything to suggest as such so I assume not. > Antony Blakey > - > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > On the other side, you have the customer and/or user, and they tend to do > what we call "automating the pain." They say, "What is it we're doing now? > How would that look if we automated it?" Whereas, what the design process > should properly be is one of saying, "What are the goals we're trying to > accomplish and how can we get rid of all this task crap?" > -- Alan Cooper > > >
[jira] Created: (COUCHDB-393) Cannot discover currently running http port if ini file specifies port 0
Cannot discover currently running http port if ini file specifies port 0 Key: COUCHDB-393 URL: https://issues.apache.org/jira/browse/COUCHDB-393 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Affects Versions: 0.9 Environment: Ubuntu 9.04 Reporter: Stuart Langridge It is currently not possible, if the ini file specifies port 0 as the http port (so that the OS chooses a random port) to discover which port the OS actually chose. It would be nice if the currently running port was made available in the statusline output (couchdb -s), but a log statement would be adequate; some way that an external script can discover which port a running CouchDB is listening on. Edited discussion from #couchdb: aquarius: well at a glance it appears couch_http passes the 0 to mochiweb_http which passes it to the mochiweb_socket_server, which passes it to gen_tcp, an erlang module that lets the underlying OS assign it. mochiweb_socket_server then grabs that port and stores it. It has a get method to retrieve properties but that needs to be exposed to mochiweb_http so it would take a little work to do it. It's probably a JIRA ticket, unless someone else sees a quicker approach bitdiddle: you got that far and didn't find it? davisp: is there a better way to find the port? oh, is that not the bind port? I was just thinking a log statement davisp: the problem is if you specify 0 as the bind port (so the OS chooses a port), how do you find out what was chosen? aquarius: you have to look at the port returned by the socket aquarius: in other words, CouchDB was never written to do that AFAIK davisp: I found it, just needs some work to expose it aquarius: and by do that, I mean, we never put in a statement to log that mochiweb_http is the module that needs to bubble it up davisp: I don't really mind whether it's a log statement or it's exposed to couchdb -s (the latter seems tidier to me, but whichever), I just want to be able to start couch on port 0 and then later find out which port got chosen :) aquarius: for the time being you can use something like netstat or lsof, but we'll get a log statement in there or something -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-392) list and show responses should send utf-8 by default
list and show responses should send utf-8 by default Key: COUCHDB-392 URL: https://issues.apache.org/jira/browse/COUCHDB-392 Project: CouchDB Issue Type: Bug Components: JavaScript View Server Reporter: Chris Anderson Fix For: 0.10 we get this wrong currently, making unicode characters display as gibberish by default in most browsers. It's as simple as making the response headers include: "Content-type":"text/html; charset=utf-8" so that the browser understands what we're sending. We always work in utf-8 so this should be the default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-391) Restoring the couchDB (restore Documents Views on different Servers)
[ https://issues.apache.org/jira/browse/COUCHDB-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Katz closed COUCHDB-391. --- Resolution: Invalid Please ask questions in the appropriate CouchDB mailing list, not in the bug system: http://couchdb.apache.org/community/lists.html > Restoring the couchDB (restore Documents Views on different Servers) > > > Key: COUCHDB-391 > URL: https://issues.apache.org/jira/browse/COUCHDB-391 > Project: CouchDB > Issue Type: Question > Environment: Microsoft Windows XP Professional version 2002 > service Pack2 > erlang : 5.6.5 > couchDb : 0.9.0 >Reporter: Ajay jagdish Pawaskar > > i want to restore the CouchDB Documents & Views from One server to another > (on clients server) > there is option for replication (remote server)..but i don't have access to > that server...(so i can't Replicate DB on that server using Replicator) > ..but i need to deploy the Db on that server > .. also in future maybe i will be needing the documents from client server > for debugging purpose > how i can do this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-391) Restoring the couchDB (restore Documents Views on different Servers)
Restoring the couchDB (restore Documents Views on different Servers) Key: COUCHDB-391 URL: https://issues.apache.org/jira/browse/COUCHDB-391 Project: CouchDB Issue Type: Question Environment: Microsoft Windows XP Professional version 2002 service Pack2 erlang : 5.6.5 couchDb : 0.9.0 Reporter: Ajay jagdish Pawaskar i want to restore the CouchDB Documents & Views from One server to another (on clients server) there is option for replication (remote server)..but i don't have access to that server...(so i can't Replicate DB on that server using Replicator) ..but i need to deploy the Db on that server .. also in future maybe i will be needing the documents from client server for debugging purpose how i can do this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-380) Getting "please try again." response from CouchDb when tried to update the document
[ https://issues.apache.org/jira/browse/COUCHDB-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ajay jagdish Pawaskar closed COUCHDB-380. - ya.. i messed up with the revisions..so in that case i was giving message Please try Again > Getting "please try again." response from CouchDb when tried to update the > document > --- > > Key: COUCHDB-380 > URL: https://issues.apache.org/jira/browse/COUCHDB-380 > Project: CouchDB > Issue Type: Question >Affects Versions: 0.8 > Environment: Microsoft windows Xp Professional version 2002 Service > Pack 2 > Microsoft Visual C# 2005 >Reporter: Ajay jagdish Pawaskar >Assignee: Paul Joseph Davis >Priority: Blocker > Fix For: 0.10 > > > hi > i m Updating couch document from >net framework 2.0 (c#) > i m getting response as "please try again" > (when i am updating other docs those docs getting updated) > here is what i m doing > i have two docs > 1] appconfiguarion > 2] systemrestore > i m getting (GET) systemrestore & appconfiguarion > then in my .net code i update the appconfiguarion from systemrestore > document ( taken care of _id & _rev Fields) > then i am trying to update(PUT) the appconfiguarion document > where i m getting error as "please try again" > . > . > . > one more thing > when i m updating appconfiguarion document separately it's getting updated > (from my .Net code) > . > . > . > i tried by restarting couchDb server same error i am getting > . > is any any kind of BUG from couchdb? > or m i missing something? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-390) proposed additions to _changes feed
proposed additions to _changes feed --- Key: COUCHDB-390 URL: https://issues.apache.org/jira/browse/COUCHDB-390 Project: CouchDB Issue Type: New Feature Reporter: eric casteleijn The _changes comet feed as a replacement for the update notifications is a great step forward, but I'm currently missing these features: 1. The feeds are now per database, rather than per server, which is nice in some use cases, but in others it's preferable to have a server wide feed (In the case of many thousands of databases on a server, and a single process reacting to updates, by putting messages on a message queue for instance). Ideally I'd like to have both server wide and per database _changes feeds available. 2. I'd like to have a configurable _changes feed that let's me declare what data will be output in the update rows in the feed, in a similar way to writing views. 3. I'd like to (optionally) have information on whether a particular update was a document creation, update or deletion, so clients would be able to react to those differently without needing to query into the database to find out what happened. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Unicode normalization (was Re: The 1.0 Thread)
On 23/06/2009, at 11:22 AM, Noah Slater wrote: Could Unicode normalisation affect the sorting of keys with option two? On a related issue: the locale certainly could e.g. it changes the collation order of accented characters. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 On the other side, you have the customer and/or user, and they tend to do what we call "automating the pain." They say, "What is it we're doing now? How would that look if we automated it?" Whereas, what the design process should properly be is one of saying, "What are the goals we're trying to accomplish and how can we get rid of all this task crap?" -- Alan Cooper
Re: Unicode normalization (was Re: The 1.0 Thread)
On Sun, Jun 21, 2009 at 11:21:00PM -0700, Chris Anderson wrote:
> A normal
> user is not going to understand the first bit of the fact that the
> underlying binary representation of their text could be subtly
> different in a way that would be invisible to them.
...
> Secondly, we're a database, so I find highly suspicious the notion
> that we should auto-normalize user input on-the-quiet.
Then maybe is it worth going the whole hog, and just storing the received
JSON directly to disk as a string? This takes out the JSON->erlang parsing
when storing documents, and the erlang->JSON serialisation when sending on
to the view server, or when retrieving documents for the client.
Of course, there is metadata which CouchDB adds, like _id, _rev etc. This
could be stored separately alongside the document, and then shoehorned in
when you retrieve the document (e.g. as simple as inserting some text after
the initial '{').
This gives some interesting future options: e.g. moving the metadata into
HTTP headers, at which point there is no requirement for the document to be
in JSON form at all. It just has to be in some format that the view server
is happy to parse.
As an aside: I support that subtly different encodings of the "same"
document (according to NFC) should have different revs, because (a) it's
unlikely that multiple different client implementations will be making the
same changes to the same documents (i.e. the clients in a cluster are likely
to be homogeneous), and (b) such conflicts are easy to resolve anyway.
Furthermore:
> "don't mutilate strings you didn't edit" so as long as client software
> doesn't go jiggling forms to other random look-alike codepoints
> without asking, any potential trouble is confined to fields actually
> effected by an update.
It's probably not reasonable to make this requirement. Most client software
will deserialise JSON into some internal form (a Ruby hash, a Python dict,
or whatever), at which point transformations will take place, so turning it
back into JSON may well not give exactly the same serialisation. Ruby 1.8
won't even maintain the member ordering.
Re: The 1.0 Thread
+1 for anything which can improve performance of generating views, especially when importing large datasets. Maybe it's just me, but CouchDB "feels" much slower than an RDBMS for this. That is, an RDBMS might limit you to only a couple of hundred inserts per second, but at least all your indexes are being built too. With CouchDB I can bulk-insert 600+ docs per second on an old laptop but the subsequent view generation takes far, far longer. CouchDB ought to have some advantages over the RDBMS: all the 'new' docs are contiguous on disk, and it can add to its btrees in bulk, rather than once per insert. However it has handicaps too, notably erlang->JSON->JS->JSON->erlang serialisation and the associated context switches. I only just started profiling this and I don't see anything obviously bad, but I have a real-world app which only manages to index 10 or 20 docs per sec (emitting an average of ~10 K/V pairs per doc), admittedly with a bit of regexp munging in the Javascript view code.
Re: The 1.0 Thread
On 23/06/2009 3:51 AM, Jim McCoy wrote: Something that would be nice to have for 1.0 or at least somewhere on the roadmap is full support for Erlang in views and in other bits of the codebase that accept functions as input. I know that Javascript is quite popular with most of the Couch team, but it would be nice to know that Erlang could be used from top to bottom in the Couch stack rather than having to remember which bits are in Erlang and which are in Javascript (at least for those of us who are in that odd minority that do more Erlang coding than Javascript coding...) Please check out https://issues.apache.org/jira/browse/COUCHDB-377 and feel free to update as per Damien's recent comments - I'm very very new to erlang and very busy at the moment, so it might take me a while... Cheers, Mark
