LoadAsync with many ids == returns Dictionary? (Raven4)

28 views
Skip to first unread message

Marcelo Volmaro

unread,
Jul 17, 2017, 2:24:12 PM7/17/17
to RavenDB - 2nd generation document database
I know that maybe was done to help as it would allow me to access each item by ID, but also that creates a new dictionary every time I use the method and most of the time, I don't need the dictionary for lookup.

Just saying that maybe the old behavior of returning an IEnumerable<T> (or IReadOnlyCollection, or whatever you want that has the least possible allocations) instead of the dictionary would be better, simply to not allocate one (and if I need that feature, it is really easy to do an extension method that solves that for me automatically).


Oren Eini (Ayende Rahien)

unread,
Jul 17, 2017, 2:54:52 PM7/17/17
to ravendb
Since there is going to be an allocation here anyway, I'm not quite sure what the object is, to the fact that we return a dictionary?

Hibernating Rhinos Ltd  

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

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

 


On Mon, Jul 17, 2017 at 9:24 PM, Marcelo Volmaro <mvol...@gmail.com> wrote:
I know that maybe was done to help as it would allow me to access each item by ID, but also that creates a new dictionary every time I use the method and most of the time, I don't need the dictionary for lookup.

Just saying that maybe the old behavior of returning an IEnumerable<T> (or IReadOnlyCollection, or whatever you want that has the least possible allocations) instead of the dictionary would be better, simply to not allocate one (and if I need that feature, it is really easy to do an extension method that solves that for me automatically).


--
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.

Marcelo Volmaro

unread,
Jul 17, 2017, 3:03:32 PM7/17/17
to RavenDB - 2nd generation document database
It's not the same to allocate an array/list than to allocate a dictionary. And I'm not sure how the internals work, but probably you can simply return the result of the deserialization instead of doing a new allocation.
I'm simply saying that since I do not need the overhead of a dictionary most of the time, I think it is a waste of resources to use it.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.

Oren Eini (Ayende Rahien)

unread,
Jul 18, 2017, 4:25:53 PM7/18/17
to ravendb
Our concern is that we have seen users pass us enumerables, and then have to manually reconstruct the items that we return.
This is especially true when you have missing docs to load.
That caused a few surprises. The fault was on the consumer of the API, but the API led to making false assumptions too easily.
This is the main reason why we changed that to use a dictionary, because it prevent a common mistake in the usage.

I understand the performance cost, but given that this usually result in a network roundtrip, it isn't major, and short lived and small dictionary is pretty cheap.

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

Marcelo Volmaro

unread,
Jul 18, 2017, 5:45:55 PM7/18/17
to RavenDB - 2nd generation document database
Mmm.. I still don't get it.. if you pass an IEnumerable (that let's suppose comes from a big linq/yield/whatever) and some ids are missing, there is no way for you to know that by looking at the dictionary... The dictionary it's just for fast lookup. Any other information can be retrieved from the resultset (you already have the ids on the returned objects, and if you return an IReadOnlyCollection you can also have the count). Also, again, if you need a dictionary from the resultset you can easily do a .ToDictionary(x=>x.Id, x=>x), and you will get the same information (unless you are filling in the dictionary with the missing values too...)

Either way, you can do a .ToList() first to the IEnumerable so you don't have to compute it twice and then a .ToDictionary on the resultset. A simple loop over the list and doing a TryGet on the dictionary will solve that, and I believe that's a specific use case that the user needs to handle, and not the DB. And (and of course, this is my opinion on this), if the user don't know how to do that.. well, you have bigger problems then... :)

Oren Eini (Ayende Rahien)

unread,
Jul 19, 2017, 1:47:15 AM7/19/17
to ravendb
The dictionary will contain an entry for any id that you put in. If the doc doesn't exist, you'll get a null there.
Previously we put a null in the dictionary, and that caused people to get NRE and led to convoluted code to get id / doc matching in some cases.
In particular, you can't do (id == x.Id) because that is case sensitive comparison and ravendb ids are case insensitive.

The dictionary we return has the keys in the same case as you gave us, and it is much more natural behavior WRT to missing documents.

To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages