Packages

  • package root
    Definition Classes
    root
  • package gnieh
    Definition Classes
    root
  • package sohva

    Contains all the classes needed to interact with a couchdb server.

    Contains all the classes needed to interact with a couchdb server. Classes in this package allows the user to:

    • create/delete new databases into a couchdb instance,
    • create/update/delete documents into a couchdb database,
    • create/update/delete designs and views,
    • manage built-in security document of a given database,
    • create/update/delete couchdb users,
    • use couchdb authentication API to create sessions and use built-in permission system.
    Definition Classes
    gnieh
  • package mango

    The [mango query server](http://docs.couchdb.org/en/2.0.0/api/database/find.html) was introduced in CouchDB 2.0.

    The [mango query server](http://docs.couchdb.org/en/2.0.0/api/database/find.html) was introduced in CouchDB 2.0. It allows for querying documents in a database with a declarative syntax and is easier to use that the classic CouchDB views.

    Definition Classes
    sohva
  • package strategy
    Definition Classes
    sohva
  • BarneyStinsonStrategy
  • Strategy
  • StructuralMergeStrategy
  • TedMosbyStrategy
p

gnieh.sohva

strategy

package strategy

Ordering
  1. Alphabetic
Visibility
  1. Public
  2. All

Type Members

  1. trait Strategy extends AnyRef

    A strategy indicates how update conflict are resolved.

    A strategy indicates how update conflict are resolved. It is used by the conflict resolver at each try and may be called several times with the same document if the document changed while the strategy was applied.

Value Members

  1. object BarneyStinsonStrategy extends Strategy

    This strategy applies a simple rule: New is always better Whenever a conflict occurs when trying to save a document in the database, the newest document (the one the client wants to store) is taken and overrides the previous revision.

  2. object StructuralMergeStrategy extends Strategy

    This strategy applies a simple structural merge algorithm between variation from a base document to the last one in the database and from the base to the current revision of the document to merge

    This strategy applies a simple structural merge algorithm between variation from a base document to the last one in the database and from the base to the current revision of the document to merge

    In our case, the base document is taken as common ancestor and we create patches that models these changes:

    • let's name document base, db and current respectively the base document, the last document from the database and the document one wants to save
    • let BD be the name of the patch from base to db and BC be the patch from base to current.
    • compute DC the patch that makes the same modifications as BC but in the context of document db
    • apply this patch to db

    The rules to apply when merging paths are the following:

    `BD` `BC` `DC`
    Not Changed Not Changed Not Changed
    Not Changed Changed Changed
    Not Changed Deleted Deleted
    Changed Not Changed Changed
    Changed Changed Changed (`BC`)
    Changed Deleted Deleted
    Deleted Not Changed Deleted
    Deleted Changed Deleted
    Deleted Deleted Deleted
    Added Not Changed Added
    Added Added Added (`BC`)
    Not Changed Added Added

    As a special case, if the document was deleted inbetween, the current document is saved "as is" in the database (without revision)

  3. object TedMosbyStrategy extends Strategy

    This strategy is the anti-BarneyStinsonStrategy by definition as it applies a simple rule: Old is always better.

    This strategy is the anti-BarneyStinsonStrategy by definition as it applies a simple rule: Old is always better. Whenever a conflict occurs when trying to save a document in the database, the oldest document (the one from the database) is kept.

Ungrouped