3 ms·
My problem with this approach is that this falls apart if you write: db.Select<Person>(x => Regex.IsMatch(x.FirstName, "^A.*")); This would fail at run-ti
by Pxtl 2y ago
My problem with this approach is that this falls apart if you write:
db.Select<Person>(x => Regex.IsMatch(x.FirstName, "^A.*"));
This would fail at run-time instead of compile-time.
That's why I'd rather see the DB classes auto-generated with a mapper to convert them. Having the "master" be POCOs instead of JSON/XML/YAML/whatever isn't something I'm convinced on in either direction, but imho the in-database classes being not real POCOs is the important part because it reduces the the problem of somebody writing Person.MyMethod() and then blowing up because it's not a SQL function.
- mythz 2y agoIsn't this just `.StartsWith("A")`? How would you perform this regex query with your code generated solution? What would have to be code generated and what would the developer have to write? As there's a lot more features available in different RDBMS's than what's available in C# expression syntax, you can use SQL Fragments whenever you need to: var results = db.Select(db.From<Person>() .Where(x => x.LastName == "B") .And("FirstName ~ '^A.*'"));
- Pxtl 2y agoYes, it's a trivial example. I'm not looking to support it, I'm looking to catch it at compile-time. if "Person.FirstName" is a string, then that encourages users to use string-operations against it, which will fail if this expression is being translated to SQL for executing in the DB. if "Person.FirstName" is some other type with no meaningful operations supported on it (which will get converted into a string when the query is executed) then it prevents many many classes of logic errors.