Add Lucene Document parameter to factory Func

[mcintyre321]

I extended my previous pull request https://github.com/themotleyfool/Lucene.Net.Linq/pull/16 to include change tracking, even when the object has been looked up, rather than re-materialised.

I did this by storing the original field values in the Tracking object, rather than holding a clone of the original object. Hope it's ok!

[mcintyre321]

Can I ask what your thoughts are on this? Is this acceptable, or do I need to further abstract the Tracking strategy

[chriseldredge]

Taking a look at this one today.

[chriseldredge]

I've modified the library so it should not create duplicate entities when using session/document tracking in 2c87f23bafa1a5ffb37dd74172cdff3dd17ad2fa. My approach is a little different than yours and has the added benefit of allowing the client to provide their own implementation of IDocumentModificationDetector<T>.

Please let me know if this addresses the issue.

[chriseldredge]

See Samples/PropertyChangeExample.cs for an example that uses INotifyPropertyChanged to track dirty items.

[mcintyre321]

The original reason for me needing to change the indexing method was so that I could lookup the original objects from an id, rather than re-creating them from the Stored document (so the factory uses Func<Document, T> instead of Func).

Is is possible for you to add that in?

[Loupi]

Hi,

Sorry to jump in here abruptly, this additional parameter to the factory would be a very useful addition.

I'm currently developing a graph database in .NET with managed ESENT. It is based on a port of TinkerPop Blueprints that I made: https://github.com/Loupi/Frontenac .

I'd like to use Lucene.NET to index the data contained in my GraphDB, analyze all, store only pk, perform complex search, get pk as a result, then load the data out of the GraphDB.

[chriseldredge]

Please review 76ca330fd12ad3482c9f703fc4a986b52e3339e1 which adds overloads to CreateSession and AsQueryable that provide an IDocumentKey instance to the delegate method.

I think using IDocumentKey is better than Document because it allows the client to keep working on the abstracted level instead of needing to reach into Document directly.

Please let me know if this meets your needs.

[Loupi]

Chris, I reviewed the code and it looks like it will perfectly meet the requirements of my GraphDB. I'm going to download and try a custom build.

Thank you!

[mcintyre321]

I've tried updating my Linqdex project to use your latest code, but I'm not sure what how to implement the new properties on IDocumentKey (Properties and the indexer). Could you give me a few pointers please?

My class is at https://github.com/mcintyre321/Linqdex/blob/master/Linqdex/Key.cs

On 5 August 2013 23:32, Louis-Pierre Beaumont notifications@github.comwrote:

Chris, I reviewed the code and it looks like it will perfectly meet the requirements of my GraphDB. I'm going to download and try a custom build.

Thank you!

— Reply to this email directly or view it on GitHubhttps://github.com/themotleyfool/Lucene.Net.Linq/pull/27#issuecomment-22145927 .

[chriseldredge]

Those new properties are intended to allow the client to get the key/values from an IDocumentKey in order to look up an entity instance. In your look up delegate, you could either do

var key = documentKey[documentKey.Properties.Single()];

Or you could expose the single key value on your implementation and do something like

var key = ((Key)documentKey).Value;

I submitted a quick pull to your class.

[mcintyre321]

Thanks Chris. Your pull hasn't come through, but it looks like your changes will be suit me just fine, so I will wait for the Nuget update, then update Linqdex (and rename it! Hideous name!).

[chriseldredge]

Released in v3.2.52 and published on NuGet.org.