[
https://issues.apache.org/jira/browse/COUCHDB-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797609#action_12797609
]
Iain Sproat commented on COUCHDB-615:
-
I'd like to see authorization based replication
[
https://issues.apache.org/jira/browse/COUCHDB-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797683#action_12797683
]
Chris Anderson commented on COUCHDB-615:
We already have this, in the sense that r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have 9.8 million documents which in a text file one document per line JSON
encoded comes out as 2.3Gb. Once loaded into couchdb, 21Gb of space is
consumed (after the 24 hours it takes to do a compaction!). Accounting for
the _rev field this amounts
On Thu, Jan 7, 2010 at 9:59 AM, Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I have 9.8 million documents which in a text file one document per line JSON
> encoded comes out as 2.3Gb. Once loaded into couchdb, 21Gb of space is
> consumed (after the 24 hours it takes to
0.9->0.10 upgrade rebuilds views rather than just updating headers
--
Key: COUCHDB-616
URL: https://issues.apache.org/jira/browse/COUCHDB-616
Project: CouchDB
Issue Type: Bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Anderson wrote:
>> You might try using CouchDB's builtin sequential "uuids". These should
>> give you some more storage efficiency.
I can't as various items reference various other items. The source data is
in a SQLite database - highly normali
The sequential uuids mentioned above are a configuration option. Since
it's implicit in what you've said, you must be allowing couchdb to
generate uuids on the server-side, otherwise the inefficiencies that
they cause would not be in your report. Switch the setting and try
again, I think it remedie
[
https://issues.apache.org/jira/browse/COUCHDB-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana updated COUCHDB-583:
--
Attachment: couchdb-583-trunk-8th-try.patch
+ Updated patch to gracefully merge with the lates
On Thu, Jan 7, 2010 at 3:53 PM, Robert Newson wrote:
> The sequential uuids mentioned above are a configuration option. Since
> it's implicit in what you've said, you must be allowing couchdb to
> generate uuids on the server-side, otherwise the inefficiencies that
> they cause would not be in you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Newson wrote:
> The sequential uuids mentioned above are a configuration option. Since
> it's implicit in what you've said, you must be allowing couchdb to
> generate uuids on the server-side,
Sorry if I wasn't clear but your statement above is
Are the sequential uuids in 0.10 ?
I added the config option
[uuid]
algorithm=sequence
It didn't seem to have any impact.
first id was 4 next one was b
if it were sequential wouldn't they all start with 4 then 5 then 6 etc?
Thanks,
Nick
2010/1/8 Chris Anderson
> On Thu, Jan 7, 2010
On Thu, Jan 7, 2010 at 5:31 PM, Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Robert Newson wrote:
>> The sequential uuids mentioned above are a configuration option. Since
>> it's implicit in what you've said, you must be allowing couchdb to
>> generate uuids on the ser
On Thu, Jan 7, 2010 at 5:36 PM, Nicholas Orr wrote:
> Are the sequential uuids in 0.10 ?
>
> I added the config option
>
> [uuid]
> algorithm=sequence
I think you need sequential instead of sequence.
>
> It didn't seem to have any impact.
> first id was 4 next one was b
> if it were sequ
13 matches
Mail list logo
