Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make the view_changes API more simple #8

Closed
benoitc opened this issue May 14, 2012 · 1 comment
Closed

make the view_changes API more simple #8

benoitc opened this issue May 14, 2012 · 1 comment

Comments

@benoitc
Copy link
Contributor

benoitc commented May 14, 2012

Actually the view changes api in #1 imply to add the option seq_indexed: true to either design doc options to get view changes without the view arguments:

{
    "_id": "_design/test",
    ...

    "options": {
        "seq_indexed": true
    }
}

or view options to filter the view by key, start_key or end_key:

{
    "_id": "_design/test",
    ...

    "views": {
        "someview": {
            "map": "function(doc) { emit(null, doc); }",
            "options": {
                "seq_indexed": true
            }
        }
    }
}

Which complicate a little the API for little benefice imo. The main benefice is to reduce the disk usage by only indexing needed views. I'm thinking to simplify the API by using only one global design doc options seq_indexed: true . Then we could:

  • either index each views (one seq btree / view) like the seq_indexed: true options applied to a view gave
  • or do this filtering only in memory by streaming all results in a view which would be less efficient for ranges & key queries but would use less disk by only requiring a view group index (one index for all the design document).

Thoughts?

@benoitc
Copy link
Contributor Author

benoitc commented Jun 22, 2012

applied in last head

@benoitc benoitc closed this as completed Jun 22, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant