A personal Blazor blog.
Showing posts tagged Linq.
Inspired by an amazingly concise implementation of John Conway's game of Life that I saw written in APL, I decided to see if I could write Life in a single Linq expression.
This (rather long and rambling) post documents my attempts, my eventual success and the result that it made me want to learn APL!
As a (somewhat lapsed but still interested) mathematician, I like to play around with interesting numbers. Well, I guess we all have our little foibles eh?
I decided to have a go at generating pairs of amicable numbers using Linq. This post explains what they are, and how I went about it.
I was browsing the latest C# questions on StackOverflow, and came across one that caught my eye. Sadly, it was quickly closed by people who, in my opinion, didn't read it properly. The question was...
I am trying to write a program to find the factor of a number with minimum difference. For Ex: for 20 it should be 4x5 or vice versa. How can this be achieved for a really BIG number. lets say 989287498274928743928174192847219347123984723498. Please guide
Ignoring the usual SO rules about showing some effort or research, the question is not simply "How do I find the factors of n?", which is what all the linked answers were about. This question was how to find the two closest factors. Sure you can do that by finding them all, then sorting them by their difference, but for a big number, that's hugely inefficient. There are ways of solving this specific question much more efficiently, which is what I decided to do.
The latest in my vague series of posts about using LinqPad to query the schema of a database, and extract information about the database as a whole. In this case, it was finding the number of rows in each table, and whether any were empty.
Inspired by a long-defunct billboard advert, I coded up a Linq expression to find the first 10-digit prime found in consecutive digits of e. This turned out to be disappointingly easy
Ever wondered what the prime factors of your telephone number are? No, nor had I until I read Humble Pi. A throwaway comment there led me to contemplate how to do this in a single Linq statement.
Why? Why not?
Faced with the task of modifying every varchar(n) column of every table in a database to be varchar(max), whilst avoiding default constraint errors, I came up with a script to generate the SQL for me.
I had an odd problem, the resolution of which exposed an interesting bit of information about what goes on under the C# covers that we never usually know.
I had a Linq query that worked fine on its own, but failed at run time when I extracted it into a method and passed in a lambda.
Whilst trying to work out why this was happening, I came to an understanding of the difference between a Func and an Expression, and why it (sometimes) matters.
As part of some overall auditing in one of my projects, we recently added a LastUpdatedByUserID column to all of the major tables. As the name implies, this column stores the ID of the user who last updated the row. In order to keep an audit trail of the changes, for each table in the database, we have a corresponding TableName_Audit table that is updated (by triggers on the main table) every time the main table is modified.
I noticed that for one of the tables that had had the LastUpdatedByUserID column added, the script to regenerate the audit table hadn't been run, so the audit table was missing the LastUpdatedByUserID column. This would entirely nullify the point of the column.
This led me to wonder if there were any other tables in the same state. rather than check this manually, I decided to write a script to do it, as this would be useful for future tables. Being a Linq type of person (I rarely write SQL any more), I decided to see if I could do this in LinqPad.
It took a bit of fiddling, but the end result was what I wanted, and paved the way for future queries.
It seems we aren't the only ones to find filtering and sorting child entity collections unnecessarily painful. Someone has been kind enough to write a Nuget package (part of a suite of them by the looks of things) that simplifies your code significantly.
This package removes the need for some of the tortuous hoops we had to negotiate before.
I previously blogged about a seemingly innocent LINQ problem that had me baffled for ages, which was how you sort or filter an entity’s child collection in Linq. For example, if you want to pull a collection of customers, and include all of their orders from this year, but none from earlier, then there doesn’t seem to be a simple way to do this in Linq. You need to do the query in two stages, the first which builds an anonymous type, and the second which links the to parts of it together. See that post for more details.
I also blogged about the problem of Linq not including child entities when doing joins, which requires you to cast the query to an ObjectQuery so you can use the Include() method on it.
The problem comes when you want to combine the two methods, meaning that your query needs to be constructed in two stages to ensure that the sorting or filtering of the child collection is done correctly, but you also need to cast the final result to an ObjectQuery before you send it out over WCF. The problem arises because you need to enumerate the query before doing the Include(), as that is the only way to ensure that the sorting is done, but calling AsEnumerable() gives you an IEnumerable (reasonably enough), which can't be cast to an ObjectQuery! So what's a fellow to do? Good question, and one that had me going for ages.
When you use Linq to create a query against an entity framework model, a common scenario is to use the .Include() extension method to make sure that any child objects are also loaded. This is mainly useful when the results of the query are to be sent over WCF, where the client is disconnected from the source of the query, and so cannot go back to the database to pick up any child objects as needed.
This works fine for simple queries, but falls apart when you want to do anything clever, like joins or shaping.
I came across an innocent-looking Linq problem the other day that really had me baffled for some time.
It's easiest explained using the ubiquitous Northwind database (although just about any other relational database would probably do). Suppose you want a list of customers with their orders. Pretty easy eh?
Erm no, it wasn't!