I'm using a design document to ensure that only owners can modify docs. How can I prevent couchdb from replicating this design document?
You can use the filter option in changes() and replicate(), e.g.
var opts = {
live: true,
filter: function(doc) {
return doc._id.indexOf('_design') !== 0;
}
};
var db = new PouchDB('todos');
db.replicate.to('http://localhost:5984/todos', opts);
Related
I'm using ElasticSearch to store listings. The user can sort by multiple fields (e.g. grossReturn, buyingPrice) etc.
Now we want to offer the option, that the user can store favorite listings.
Am storing the favorites in PostgresSQL. Then before each request I'm getting the favorites from Postgres - putting them in an array and have a scripted field like so:
const scripts = {
favorite: {
script: {
source: 'return params.favorites.contains(params._source.id) ? 1 : 0',
params: {
favorites,
},
},
},
};
Now I also want to sort by this field and this is the problem:
const getSortParams = (sortBy, scripts) => {
const sort = {};
if (sortBy) {
const fieldName = sortBy.split(',')[0];
const sortOrder = sortBy.split(',')[1];
if (fieldName === 'favorite') {
sort._script = {
type: 'number',
script: scripts[fieldName].script,
order: sortOrder,
};
} else {
sort[fieldName] = {
order: sortOrder,
};
}
}
return sort;
};
It is very very slow - sorting taking roughly 3s. It makes sense since everything needs to be calculated.
My question would be -> what is a better way to do this?
Add a property to your listing definition class that would indicate whether it's a favourite or not (true, false).
Since its per user basis, maybe add an array property for your user model that would store an array of favourite listing ids.
I am trying to create an Elasticsearch MLT query using NEST's object initializer syntax. However, the final query when serialized, is ONLY missing the MLT part of it. Every other query is present though.
When inspecting the query object, the MLT is present. It's just not getting serialized.
I wonder what I may be doing wrong.
I also noticed that when I add Fields it works. But I don't believe fields is a mandatory property here that when it is not set, then the MLT query is ignored.
The MLT query is initialized like this;
new MoreLikeThisQuery
{
Like = new[]
{
new Like(new MLTDocProvider
{
Id = parameters.Id
}),
}
}
MLTDocProvider implements the ILikeDocument interface.
I expect the serialized query to contain the MLT part, but it is the only part that is missing.
This looks like a bug in the conditionless behaviour of more like this query in NEST; I've opened an issue to address. In the meantime, you can get the desired behaviour by marking the MoreLikeThisQuery as verbatim, which will override NEST's conditionless behaviour
var client = new ElasticClient();
var parameters = new
{
Id = 1
};
var searchRequest = new SearchRequest<Document>
{
Query = new MoreLikeThisQuery
{
Like = new[]
{
new Like(new MLTDocProvider
{
Id = parameters.Id
}),
},
IsVerbatim = true
}
};
var searchResponse = client.Search<Document>(searchRequest);
which serializes as
{
"query": {
"more_like_this": {
"like": [
{
"_id": 1
}
]
}
}
}
I need to search across multiple indices using OIS(Object Initializer Syntax).
I have seen examples of executing search across multiple indices with Fluent DSL, but I still do not know how to execute an equivalent search with OIS.
Here is my OIS search(Only searching against one index) :
var searchResult =
await _client.LowLevel.SearchAsync<string>(ApplicationsIndexName, "application", new SearchRequest()
{
From = (query.PageSize * query.PageNumber) - query.PageSize,
Size = query.PageSize,
Query = GetQuery(query),
Aggregations = GetAggregations()
});
Which modifications can be done, so I can search across multiple indices?
After some research, I found out how to search across multiple indices:
var searchResult =
await _client.LowLevel.SearchAsync<string>(new SearchRequest()
{
IndicesBoost = new Dictionary<IndexName, double>
{
{ "applications", 1.4 },
{ "attachments", 1.4 }
},
From = (query.PageSize * query.PageNumber) - query.PageSize,
Size = query.PageSize,
Query = GetQuery(query),
Aggregations = GetAggregations()
});
Rethinkdb docs has this example to improve getAll/contains queries with a secondary index:
// Create the index
r.table("users").indexCreate("userEquipment", function(user) {
return user("equipment").map(function(equipment) {
return [ user("id"), equipment ];
});
}, {multi: true}).run(conn, callback);
// Query equivalent to:
// r.table("users").getAll(1).filter(function (user) {
// return user("equipment").contains("tent");
// });
r.table("users").getAll([1, "tent"], {index: "userEquipment"}).distinct().run(conn, callback);
My questions is if there's a way to do the same but for querying with multiple tags. What would be the equivalent to make this query possible with a secondary index?
r.table("users").getAll(1).filter(function (user) {
return user("equipment").contains("tent", "tent2");
});
Probably we can do this
r.table("users").getAll([1, "tent"]).filter(function (user) {
return user("equipment").contains("tent2");
});
So build a multi index as you did, and try to getAll first, so that part is efficient with index, then filter to continue ensure that equipment contains array we want.
I am using meteor to implement a 'near' query.
In fact, it works well. But I am wondering how about the performance for server side.
This is the code for near query:
var geolocation = Session.get('location');
var lnglat = [0,0];
if(geolocation){
lnglat = [geolocation.longitude,geolocation.latitude];
}
if(Session.get('type') === 'near'){
return Posts.find({
location: {
$near: {
$geometry: {
type: "Point",
coordinates: lnglat
},
$maxDistance: 20000 //meters
}
}
});
}
The best answer lies in the mongodb source code in github (obviously! duh!). According to the documentation, its important to ensure the indexes. Link: http://docs.mongodb.org/manual/core/geospatial-indexes/