Indexing for name lookup vs. patching

[Steven Roberts]

Hi,

This is more of a general "approach" question than technical I think

I have the following structure that tracks links between different entities

id-a

   id-b

   id-c

id-b

   id-a

   id-c

id-c

   id-a

   id-b

these are all ids that point to each other really.  This list can grow fairly long I would imagine 150+ root ids, all pointed back to referencing ids.  

The problem I face is that in all display cases I need to show certain properties of the objects the ids reference, (e.g. Name, Type).  If I store these properties in the document I will have to patch it whenever the referenced entities name changes.  This may or may not occur frequently but it's an extra step and if I extend the properties kept to include Status for example, the patching will become even more frequent.  The alternative is to use an index to keep these properties, but I'm concerned about the performance of calling LoadDocument for so many ids.

Anyone have any thoughts on this?

[Oren Eini (Ayende Rahien)]

How often will those 150+ ids change?

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steven Roberts]

I assume you mean how often will the link/references change and/or the root list of ids; I expect there to be many adds, few deletes at the beginning while the list is being built up, then a steep decline. Change in the source entity will continue throughout the life cycle but probably sporadic. Adding status to that mix or other properties would increase the number of changes.

--
You received this message because you are subscribed to a topic in the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ravendb/3apzsVFyKtU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ravendb+unsubscribe@googlegroups.com.

[Oren Eini (Ayende Rahien)]

Any modification to the referenced document will cause it to re-index all the referencing documents. That is probably not a good idea in this case.

[Steven Roberts]

So... better to keep the properties local and patch?

[Oren Eini (Ayende Rahien)]

Yes, but that being the case, you'll need to reindex them anyway.

Can you provide the real use case?

[Steven Roberts]

sure

In my model I have a root Project object.  It is mostly updated infrequently once created.

Each Project has any number of 3 types of children (Requirement, Solution, TestScenario).  The children are not added to the Project, but instead have a ProjectId property.  Each Project has a separate Map Entity that tracks how each of the 3 children are related to each other.  My intention was to patch the mapping entity every time a child was added.  Separately a single user can map the children together, so again the document gets updated but only playing with ids.

My first thoughts were to only include the ids in this Map document.  Since I would only be adding/removing ids I can deal more easily with concurrency issues.  The problem is, that to display the map, I need each child's name property.  To do that I would need to load each of the children.  I think that's too much to do on the client side, although I had also considered transformers using LoadDocument, I still seems a lot of overhead.  So I was considering using an index, but was thinking that the index would need to be updated to frequently.

My second thoughts were to include the child's name property in the map document.  That means my queries are instant, but it means every time a child's name is updated I have to update Map entity.  This would lead to more concurrency issues I fear.

Does that help explain?

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ravendb/3apzsVFyKtU/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ravendb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ravendb/3apzsVFyKtU/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ravendb+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.

[Oren Eini (Ayende Rahien)]

Why no do that as a transformer? This way, you only do that when you actually need to load the values?

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.

[Steven Roberts]

I had considered that but can I transform from a load? I don't foresee this document ever being queried as there is only one per project hierarchy.

To unsubscribe from this group and all its topics, send an email to ravendb+unsubscribe@googlegroups.com.

[Steven Roberts]

I see that I can indeed transform on load.  Thank you I will try that.

[Steven Roberts]

Transforming on load works great, but 2 questions.

1.  Are there limitations doing a LoadDocument in the transformer, for example if I have more than 128 documents to load am I going to get an error?

2.  When I call Session.LoadAsync<TResult>(string id, Type transformerType...  It appears as if this gets translated to a query instead of an actual load, is this correct?

[Oren Eini (Ayende Rahien)]

1) No, but be careful there, it will take O(N) time, obviously.

2) No, ti is a load

Hibernating Rhinos Ltd  

Oren Eini l CEO l Mobile: + 972-52-548-6969

Office: +972-4-622-7811 l Fax: +972-153-4-622-7811

 

[Steven Roberts]

the url look like "/queries/?&transformer=mytransformer&id=123" vs. "/docs?id=123" is that just a semantic way of telling the server it's not just a document load?

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.

[Oren Eini (Ayende Rahien)]

That is a document load, actually.

Query will look like "indexes/INDEX_NAME?query=...

You can consider it to be a misleading endpoint name.

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.

[Oren Eini (Ayende Rahien)]

So yes, this is a way to return more than a single document, but it is doing a load

[Steven Roberts]

Thank you!

You received this message because you are subscribed to a topic in the Google Groups "RavenDB - 2nd generation document database" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ravendb/3apzsVFyKtU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ravendb+unsubscribe@googlegroups.com.