select SUM(*.itemsCount) - 2 as count from $dump where pageType = 'Index' and collection = 'chartBars';
using (var db = new LiteDatabase(_databaseFileName))
{
// Get a collection (or create, if doesn't exist)
var collection = db.GetCollection<IdentityKeyPair>(_tableName);
collection.EnsureIndex(x => x.Value);
collection.EnsureIndex(x => x.RecordId);
var entityKeyRecordId = collection.Query().Where(p => p.Value == uniqueValue).Select(x => x.RecordId).FirstOrDefault();
if (entityKeyRecordId != Guid.Empty)
results = collection.Query().Where(p => p.RecordId == entityKeyRecordId).ToList();
}
Hi, I'm currently working on a project with LiteDB 5 (5.0.8) and POCO data model classes that are isolated from the data access layer. I want to ignore certain properties but can't use BsonIgnore attribute as I want to avoid a reference to LiteDB in the data model assemblies. Instead I'm trying to use Ignore on the mapper, but while it compiles fine, it's throwing an exception saying it can't find the property to ignore it.
e.g. class property of
public bool MyProperty { get; set; }Mapper...
var mapper = BsonMapper.Global;
mapper.Entity<MyClass>()
.Ignore(x => x.MyProperty);This exception occurs on the Ignore:
Message:
System.ArgumentNullException : Value cannot be null. (Parameter 'Member 'MyProperty' not found in type 'MyClass' (use IncludeFields in BsonMapper)')
Stack Trace:
EntityBuilder`1.GetMember[TK,K](Expression`1 member, Action`1 action)
EntityBuilder`1.Ignore[K](Expression`1 member)In LiteDB 4 if multiple instances of LiteDatabase in the same process or separate processes access the same file, I believe it uses file locks and waits on the file? i.e. defaults to 'shared' mode.
In LiteDB 5, as the default is 'direct' mode, instead these situations would create an IOException for file in use, even in the same process or even thread?
At least I've observed with unit tests where I've discovered a bug in my code that was creating multiple instances of LiteDatabase in the same thread for the same database, and this was throwing IOException with file in use. The same tests in LiteDB 4 did not.
Obviously if it's intended 'shared' mode can be used, but I've noticed this is significantly slower seemingly than in LiteDB 4 default mode. Is this due to the use of mutexes now (instead of file locks?) and/or the closure of the database per operation ? In my tests it adds 1s or so to each DB operation and if that was scaled up it would be far too slow, so in LiteDB 5 it looks like concurrent access would be too slow. Therefore I need to design for a single process that talks to the database files and other processes communicate with that one. Which is okay though am concerned about bottleneck potential, but then the same could be true on waiting for file locks.
var collection = _db.GetCollection<IdentityKeyPair>(_tableName);
collection.Insert(identityKeyPairs);
Although this way has significantly improved performance, I still am having a performance hit. If you have any tips on improving the performance for this insert, that would be greatly appreciated
LiteCollection<T>.Insert(IEnumerable<T>) does)
LiteCollection<T>.Insert(T) for every object
a list: collection.Insert(identityKeyPairs); Unfortunately, it has to be like this, as we cant wait until the entire file processes to do the insert
LiteCollection<T>.Insert(T) for every object in a single transaction (between calls to db.BeginTrans() and db.Commit()). It is possible that the overhead is smaller this way, but I'm not sure.
db.BeginTrans();
foreach(var item in identityKeyPairs)
collection.Insert(item);
db.Commit();Insert(IEnumerable<T>) is that in case the loop doesn't finish (process crash, power loss, exception...), all inserted items will be discarded (because they are part of an unfinished transaction).
Hi guys,
I'm trying to use litedb as a log event storage,
public class LogMessage
{
public string Level { get; set; }
public string Message { get; set; }
public Dictionary<string, string> Properties { get; set; } = new Dictionary<string, string>();
}Name, you could simply run the query select $ from logevents where $.Properties.Name != null