Re: CouchDB OTP
On Nov 3, 2010, at 11:53 PM, Noah Slater wrote: 7. Removing dependencies from the source tree is not going to happen any time soon. I wish we didn't have to vendor so many projects, but we have to remember that a majority of people building CouchDB are not Erlangians. Forcing our community to install a number of Erlang dependencies to build CouchDB would be a very large hurdle to navigate. I know that there are projects like faxien and rebar's git support to overcome this, but I don't feel that there is a solution that sufficiently addresses this issue. And doing it at build time breaks a really fundamental rule of build systems. Never assume a network connection Can we remove the dependencies from the repository but include them in all release tarballs? For example, in a rebar world we would call 'get-deps' in the course of building a release tarball. Throwing away the commit history of our upstream dependencies makes regression-hunting more difficult than it needs to be. Adam
Re: CouchDB OTP
On 4 Nov 2010, at 03:53, Noah Slater wrote: Autotools is a big, stinking, POS — but it gets the job done, precisely because it's been around for 20 years. [1] This software has been tested on and ported to so many systems, it would make your mind boggle. If you're distributing source packages to a large user-base, especially with C code, there are very few sensible alternatives. Something occurred to me after sending this email. I wrote the CouchDB build system three years ago now. The only major changes I've ever made to it since then have been additions for new pieces of CouchDB proper. The amount of bugs that are found in it are minimal, to say the least. They say that data matures like wine, and software matures like fish — but it's been one of the most enduring bits of code I've probably ever produced. And I credit that entirely to the Autotools maintainers. Hehe.
Re: multi columns
hi! On Wed, Nov 3, 2010 at 5:32 PM, sgoto samuelg...@gmail.com wrote: hi couchdb, are there any plans for supporting multi columns in couchdb (eg update one column for a key without re writing the entire row) ? there is no way to prevent a re-writing of a complete document, but with a document update handler ( http://wiki.apache.org/couchdb/Document_Update_Handlers) you don't have to transfer the whole document over the wire. maybe that helps? cheers, SiFu sam -- f u cn rd ths u cn b a gd prgmr !
Re: Versioning
This is how Debian distinguishes between new upstream releases versus packaging tweaks, I think it's a solid idea. B. On Thu, Nov 4, 2010 at 8:17 AM, Jan Lehnardt j...@couchone.com wrote: Hi all, Potential Bikeshed alert. -- This comes from working on CouchDBX, but is equally valid for the CouchOne platform. For CouchDBX I started out naming releases according to their CouchDB release number (e.g. CouchDBX-1.0.1). So people know what applies to them when looking for docs or asking for help. Occasionally, I'd get something wrong during packaging that would only come up after an initial release. To be able to distinguish between those releases I introduced yet another version number (CouchDBX-1.0.1-1, CouchDBX-1.0.1-2, etc.). Now my question is if that's a good enough way to version things. How e.g. would upgrades to the CouchDBX shell be denoted? Is the extra number confusing? Is any other scheme confusing? Is the matching CouchDB release numbers important enough to keep? -- The larger question here is how do we version CouchOne platform releases? The primary objective of version numbers is so users know what they get. I'm not a huge fan of using version numbers for marketing reasons, but we may get to that point so we should maybe think about maintaining an internal set of engineering version numbers and an external set of marketing version numbers even though in the beginning they are likely the same. I believe we want to be able to roll releases for all platforms with unified version numbers (1.1.0) but individual patch levels (like I do for CouchDBX) in case we fuck up packaging for a single platform, so we can release bugfixes there without having to roll the entire platform. We should nails this while we're small as our distributions will only grow, and fast. Am I overthinking this? -- What are your experiences using or creating software versions that we could learn from? Cheers Jan -- http://couchone.com/ Your Data. Anywhere.
Re: CouchDB OTP
This is a great discussion and I want it to keep going. But I'm going to try to lay out how I plan to move forward and hopefully this will help in the future. I'm going to use autotools for building only the C pieces and not for anything else. I want to be able to use this as a normal release/target system afterwards installed like any other. So I don't want to use something for placing config files or whatever. I know that won't mold well with the normal CouchDB use-case but maybe its simple to do both... Or I'll realize thats futile and do something with setting where configs live through sys.config when its passed to erlexec... Anyway, I'd hope my fork could be seen as a testbed of sorts. As I said, it should be buildable with rebar as well. Tristan On Wed, Nov 3, 2010 at 11:04 PM, Noah Slater nsla...@echolibre.com wrote: On 4 Nov 2010, at 03:53, Noah Slater wrote: Autotools is a big, stinking, POS — but it gets the job done, precisely because it's been around for 20 years. [1] This software has been tested on and ported to so many systems, it would make your mind boggle. If you're distributing source packages to a large user-base, especially with C code, there are very few sensible alternatives. Something occurred to me after sending this email. I wrote the CouchDB build system three years ago now. The only major changes I've ever made to it since then have been additions for new pieces of CouchDB proper. The amount of bugs that are found in it are minimal, to say the least. They say that data matures like wine, and software matures like fish — but it's been one of the most enduring bits of code I've probably ever produced. And I credit that entirely to the Autotools maintainers. Hehe.
Re: Versioning
On Thu, Nov 4, 2010 at 13:17, Jan Lehnardt j...@couchone.com wrote: Now my question is if that's a good enough way to version things. How e.g. would upgrades to the CouchDBX shell be denoted? Is the extra number confusing? Is any other scheme confusing? Is the matching CouchDB release numbers important enough to keep? The extra number seems in line with what other places do, so it seems alright. I suspect you would handle upgrades to the CouchDBX shell, the same way, e.g. by increasing the extra version identifier. FWIW Gentoo uses -r1 instead of -1 which I like a tiny little bit better, but it's basically a wash. Cheers, Dirkjan
Re: CouchDB OTP
On Thu, Nov 4, 2010 at 7:40 AM, Adam Kocoloski kocol...@apache.org wrote: On Nov 3, 2010, at 11:53 PM, Noah Slater wrote: 7. Removing dependencies from the source tree is not going to happen any time soon. I wish we didn't have to vendor so many projects, but we have to remember that a majority of people building CouchDB are not Erlangians. Forcing our community to install a number of Erlang dependencies to build CouchDB would be a very large hurdle to navigate. I know that there are projects like faxien and rebar's git support to overcome this, but I don't feel that there is a solution that sufficiently addresses this issue. And doing it at build time breaks a really fundamental rule of build systems. Never assume a network connection Can we remove the dependencies from the repository but include them in all release tarballs? For example, in a rebar world we would call 'get-deps' in the course of building a release tarball. Throwing away the commit history of our upstream dependencies makes regression-hunting more difficult than it needs to be. Adam I'm not entirely against this approach at first glance. Though the thing that comes to mind is how the ASF would view building release artifacts with this much code that's not in SVN. I'll ping infra to see if they have prior experience. Paul
Re: CouchDB OTP
On Thu, Nov 4, 2010 at 11:07 AM, Tristan Sloughter tristan.slough...@gmail.com wrote: This is a great discussion and I want it to keep going. But I'm going to try to lay out how I plan to move forward and hopefully this will help in the future. I'm going to use autotools for building only the C pieces and not for anything else. I want to be able to use this as a normal release/target system afterwards installed like any other. So I don't want to use something for placing config files or whatever. I know that won't mold well with the normal CouchDB use-case but maybe its simple to do both... Or I'll realize thats futile and do something with setting where configs live through sys.config when its passed to erlexec... I haven't yet spent much time contemplating how these bits are going to interact. I'll be very interested to see how you approach things here to make things work with Rebar and Sinan. Anyway, I'd hope my fork could be seen as a testbed of sorts. As I said, it should be buildable with rebar as well. Having an example on how the code looks using Sinan or Rebar will be an awesome start as I begin digging into how some of the unexciting parts of the build. I'll be watching your repo as you hack there and if you don't mind I plan on using you as a sounding board while I puzzle through these different parts. Paul Davis
Re: CouchDB OTP
Great. And I'd be more than happy to act as a sounding board. Tristan On Thu, Nov 4, 2010 at 10:26 AM, Paul Davis paul.joseph.da...@gmail.comwrote: On Thu, Nov 4, 2010 at 11:07 AM, Tristan Sloughter tristan.slough...@gmail.com wrote: This is a great discussion and I want it to keep going. But I'm going to try to lay out how I plan to move forward and hopefully this will help in the future. I'm going to use autotools for building only the C pieces and not for anything else. I want to be able to use this as a normal release/target system afterwards installed like any other. So I don't want to use something for placing config files or whatever. I know that won't mold well with the normal CouchDB use-case but maybe its simple to do both... Or I'll realize thats futile and do something with setting where configs live through sys.config when its passed to erlexec... I haven't yet spent much time contemplating how these bits are going to interact. I'll be very interested to see how you approach things here to make things work with Rebar and Sinan. Anyway, I'd hope my fork could be seen as a testbed of sorts. As I said, it should be buildable with rebar as well. Having an example on how the code looks using Sinan or Rebar will be an awesome start as I begin digging into how some of the unexciting parts of the build. I'll be watching your repo as you hack there and if you don't mind I plan on using you as a sounding board while I puzzle through these different parts. Paul Davis
Re: multi columns
what about attachments ? aren't attachments updates treated separately from document updates ? a part from indexing (map reduce and views) and security (validate_doc_updates), attachments seems to be have similar requirements. is the 'attachments' design radically different than the documents ? 2010/11/4 Siegmund Führinger s...@0xx0.net hi! On Wed, Nov 3, 2010 at 5:32 PM, sgoto samuelg...@gmail.com wrote: hi couchdb, are there any plans for supporting multi columns in couchdb (eg update one column for a key without re writing the entire row) ? there is no way to prevent a re-writing of a complete document, but with a document update handler ( http://wiki.apache.org/couchdb/Document_Update_Handlers) you don't have to transfer the whole document over the wire. maybe that helps? cheers, SiFu sam -- f u cn rd ths u cn b a gd prgmr ! -- f u cn rd ths u cn b a gd prgmr !
Re: design doc weakness (one view fails = all views fail)
Hi Mickael,
given nobody responded to this yet, I'd say it's a good idea
to file a JIRA so we don't forget looking into it :)
Cheers
Jan
--
On 7 Oct 2010, at 17:11, mickael.bai...@free.fr wrote:
Hello devs,
it seems that, on a design document, if there is one view having an error (
for example Expression does not eval to a function ) than all other views
are then unusable.
It's not critical and not a real bug, but from my (sysadmin) point of view
it's a weakness : one error on one part of the design doc leads to a totally
broken app / couchapp.
Steps to reproduce :
1/ create a new database
2/ Create a design doc :
{
_id: _design/doc1,
views: {
v1: {
map: function() {}
},
v2: {
map: thefunction() {}
}
},
language: javascript
}
3/ Create a doc :
{
_id: doc1
}
4/ Call the v1 view
What's your opinion on this ? Is it worth creating a Jira bug ?
Regards,
Mickael
Re: design doc weakness (one view fails = all views fail)
On Thu, Oct 7, 2010 at 11:11 AM, mickael.bai...@free.fr wrote:
Hello devs,
it seems that, on a design document, if there is one view having an error (
for example Expression does not eval to a function ) than all other views
are then unusable.
It's not critical and not a real bug, but from my (sysadmin) point of view
it's a weakness : one error on one part of the design doc leads to a totally
broken app / couchapp.
Steps to reproduce :
1/ create a new database
2/ Create a design doc :
{
_id: _design/doc1,
views: {
v1: {
map: function() {}
},
v2: {
map: thefunction() {}
}
},
language: javascript
}
3/ Create a doc :
{
_id: doc1
}
4/ Call the v1 view
What's your opinion on this ? Is it worth creating a Jira bug ?
Regards,
Mickael
Its definitely worth creating a JIRA issue for so that there's a place
for discussion. This has been brought up a couple times, but no one to
my knowledge has had a good idea of how to solve the issue.
For instance, if a single view breaks, all views will need to be
rebuilt when that view is fixed anyway. The only thing that comes to
mind right now is to have better error reporting so users know what's
broken.
HTH,
Paul Davis
[jira] Created: (COUCHDB-934) inside a design doc, a broken view makes all others views fail
inside a design doc, a broken view makes all others views fail
--
Key: COUCHDB-934
URL: https://issues.apache.org/jira/browse/COUCHDB-934
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Affects Versions: 1.0.1
Environment: All
Reporter: Mickael Bailly
Priority: Minor
If a design document got a broken view, all other views don't work anymore.
Steps to reproduce :
1/ create a new database
2/ Create a design doc :
{
_id: _design/doc1,
views: {
v1: {
map: function() {}
},
v2: {
map: thefunction() {}
}
},
language: javascript
}
3/ Create a doc :
{
_id: doc1
}
4/ Call the v1 view
It's annoying because :
- we're unable to know what view fails to run
- a fix on the broken view will result in the rebuilding of all other views of
the design doc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: design doc weakness (one view fails = all views fail)
I created the Jira issue.
Regards
- Mail Original -
De: Paul Davis paul.joseph.da...@gmail.com
À: dev@couchdb.apache.org
Envoyé: Jeudi 4 Novembre 2010 18h09:57 GMT +01:00 Amsterdam / Berlin / Berne /
Rome / Stockholm / Vienne
Objet: Re: design doc weakness (one view fails = all views fail)
On Thu, Oct 7, 2010 at 11:11 AM, mickael.bai...@free.fr wrote:
Hello devs,
it seems that, on a design document, if there is one view having an error (
for example Expression does not eval to a function ) than all other views
are then unusable.
It's not critical and not a real bug, but from my (sysadmin) point of view
it's a weakness : one error on one part of the design doc leads to a totally
broken app / couchapp.
Steps to reproduce :
1/ create a new database
2/ Create a design doc :
{
_id: _design/doc1,
views: {
v1: {
map: function() {}
},
v2: {
map: thefunction() {}
}
},
language: javascript
}
3/ Create a doc :
{
_id: doc1
}
4/ Call the v1 view
What's your opinion on this ? Is it worth creating a Jira bug ?
Regards,
Mickael
Its definitely worth creating a JIRA issue for so that there's a place
for discussion. This has been brought up a couple times, but no one to
my knowledge has had a good idea of how to solve the issue.
For instance, if a single view breaks, all views will need to be
rebuilt when that view is fixed anyway. The only thing that comes to
mind right now is to have better error reporting so users know what's
broken.
HTH,
Paul Davis
[jira] Commented: (COUCHDB-841) Support WebSockets in continuous changes feeds
[ https://issues.apache.org/jira/browse/COUCHDB-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12928363#action_12928363 ] David Davis commented on COUCHDB-841: - This would be a BIG feature for some of us. Let's do it! Support WebSockets in continuous changes feeds -- Key: COUCHDB-841 URL: https://issues.apache.org/jira/browse/COUCHDB-841 Project: CouchDB Issue Type: New Feature Components: HTTP Interface Affects Versions: 1.0 Reporter: Dirkjan Ochtman Just wanted to put this on the roadmap: it would be nice if continuous changes feeds (and maybe some other things in CouchDB, not sure) could support WebSockets. WebSockets are an emerging standard (there's no final spec yet) with implementations in both recent Chrome and Firefox (beta) releases that allows servers to push information to the browser without having to do polling (or longpolling). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-934) inside a design doc, a broken view makes all others views fail
[
https://issues.apache.org/jira/browse/COUCHDB-934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12928358#action_12928358
]
Sebastian Cohnen commented on COUCHDB-934:
--
The current architecture of couchdb's view system does process views in one
design document as a group. Therefore the view group fails if one view is
failing. That the view is rebuild is not duo to the fix, but duo to the fact,
that the view signature has changed. If you want to avoid this behavior, you
can use separate design documents for your views.
I have to admit that debugging a broken view can be a bit hard. There is
definitely room for improvement :)
inside a design doc, a broken view makes all others views fail
--
Key: COUCHDB-934
URL: https://issues.apache.org/jira/browse/COUCHDB-934
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Affects Versions: 1.0.1
Environment: All
Reporter: Mickael Bailly
Priority: Minor
If a design document got a broken view, all other views don't work anymore.
Steps to reproduce :
1/ create a new database
2/ Create a design doc :
{
_id: _design/doc1,
views: {
v1: {
map: function() {}
},
v2: {
map: thefunction() {}
}
},
language: javascript
}
3/ Create a doc :
{
_id: doc1
}
4/ Call the v1 view
It's annoying because :
- we're unable to know what view fails to run
- a fix on the broken view will result in the rebuilding of all other views
of the design doc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
