I am trying to use an ArrayList that contains custom objects. The array list is sorted. I am using LINQ to objects to search on multiple fields. Will LINQ to objects search use underlying sort, or it will scan through the entire arraylist.
The LINQ extension methods will not take advantage of the underlying sort. These methods are written to work on IEnumerable, and thus cannot assume anything about the underlying collection. From looking at the implementation, some LINQ methods will check if the input is an ICollection and if so call the corresponding method on that (I believe Count() works this way) to possibly avoid doing a linear scan, but in this case there is no way for LINQ to detect that your array is sorted, so it will cannot take advantage of that fact.
Furthermore, if you are doing something like myList.Where(o => o.Prop1 < 2 && o.Prop2 == 3), the Func<> passed to Where() is totally opaque to LINQ, so there's no way that it could figure out which properties are being examined even if it did know that the list was sorted.
Related
JSONata has the $keys() function which returns all the names associated with an object. I am trying to recursively apply this in order to return all of the object names that exist in a JSON tree.
This example returns the object names in nested arrays.
In an attempt to eliminate the array nesting I came up with this query ... which seems to work fine.
However, when I apply the exact same query to different JSON data as shown here the results are not fully flattened.
Q: What is the proper way to construct this query so that the results are fully flattened?
and/or
Q: What characteristic distinguishes these two datasets to account for the difference in the structure of the results?
OK, I guess I figured this out.
This query uses explicit calls to $map() and $reduce()+$append() to flatten it.
This query accomplishes the same thing using more a standard JSONata dot (.) query notation.
If I have the following code:-
IQueryable<People> list = repository.FindAllPeople;
int count = list.Count();
Then is it considered as unfeasible to count IQueryable objects and it is better to use IEnumerable?
BR
You have been misinformed.
IEnumerable will use Linq to objects, all methods are executed on objects in memory. - IQueryable will use whatever implementation of the Linq extension methods is provided by the specific provider. In this case (a repository) I would guess it is most likely a provider that maps the Linq expressions to database statements.
That means if you use IQueryable:
IQueryable<People> list = repository.FindAllPeople;
int count = list.Count();
The count is determined on the database itself, i.e. as a query "select count(*) from People". This is usually very, very fast.
If you use IEnumerable:
IEnumerable<People> list = repository.FindAllPeople;
int count = list.Count();
All People instances will be materialized to memory one by one while Linq to objects is iterating through the collection to determine the count. This will be very slow and should be avoided whenever possible.
Since not all method calls can be mapped to database queries it is sometimes unavoidable to use an IEnumerable, but all filtering, joining and grouping should be done on an IQueryable if possible, then as a last step you can use the AsEnumerable() extension methods to switch to using IEnumerable and Linq to objects.
I'm not familiar with the infeasability of IQueryable, but this blog post seems to indicate that IQueryable is much more preferable to IEnumerable because IQueryable allows access to the underlying expression.
This may only be relevant in the case of a Where clause and not impact .Count().
I got my lucene index with a field that needs to be sorted on.
I have my query and I can make my Sort object.
If I understand right from the javadoc I should be able to do query.SetSort(). But there seems to be no such method...
Sure I'm missing something vital.
Any suggestions?
There are actually two important points. First, the field must be indexed. Second, pass the Sort object into the overloaded search method.
Last time I looked, the docs didn't do a very good job of pointing out the indexing part, and certainly didn't explain why this is so. It took some digging to find out why.
When a field is sortable, the searcher creates an array with one element for each document in the index. It uses information from the term index to populate this array so that it can perform sorting very quickly. If you have a lot of documents, it can use a lot of memory, so don't make a field sortable unless there is a need.
One more caveat: a sortable field must have no more than one value stored in each field. If there are multiple values, Lucene doesn't know which to use as the sort key.
It looks like the actual method you want is e.g. Searcher.search(Query query, Filter filter, int n, Sort sort). setSort is a method of Sort.
When I call mydictionary.Add(key, object), can I guarantee that the object is added to the end of the dictionary in the sense that mydictionary.ElementAt(mydictionary.Count - 1) returns that object? I'm asking because I'm used to Java where HashMap doesn't have any order at all.
I'm hoping to use the ordering given by ElementAt as a way of knowing the order in which objects were added to the dictionary without using a separate data structure.
Update: Looks like ElementAt isn't going to be of any use. Is the best way to do this to use a separate data structure to store the ordering that I need?
Thanks
There is no order to a dictionary. The ElementAt method is a linq extension method that iterates over the dictionary using IEnumerable and counts the number of things, there is no relation to the order things were added.
There is a SortedDictionary, which will sort things by key, but will not keep them in the order they were added in.
If the order is really important you could always have two data structures, a list that you add the object to and a dictionary that stores the key to list index mapping. Or put a field inside your object that set from a counter as you add it to the dictionary.
I am new to Linq please guide me on some basic things.
In read some articles on Linq. Some authers fill data in var from Linq query, some fills list of custom type objects and some fills data in IEnumerable and some do it in IQuryable. I could not get what is difference in these 4 and which one should be used in which situation.
I want to use Linq to SQL. What should I use?
Well, you can never declare that a method returns var - it's only valid for local variables. It basically means "compiler, please infer the static type of this variable based on the expression on the right hand side of the assignment operator".
Usually a LINQ to Objects query will return an IEnumerable<T> if it's returning a sequence of some kind, or just a single instance for things like First().
A LINQ to SQL or EF query will use IQueryable<T> if they want further query options to be able to build on the existing query, with the added bits being analyzed as part of the SQL building process. Alternatively, using IEnumerable<T> means any further processing is carried out client-side.
Rather than focusing on what return type to use, I suggest you read up on the core concepts of LINQ (and the language enhancements themselves, like var) - that way you'll get a better feel for why these options exist, and what their different use cases are.