.N @netdeveloperdiary
Showing posts older than #980 · Back to latest
<название функции>(<выражение>) OVER (Сначала идёт название функции, а за ним следует предложение
<окно>
<сортировка>
)
OVER. Оно определяет область действия окна, указывая набор строк, к которым будет применяться функция. Предложение OVER является обязательной частью оконной функции. Остальной синтаксис является необязательным, и зависит от желаемой области действия:PARTITION BY можно использовать для разделения набора данных на отдельные группы (аналогично GROUP BY).ORDER BY используется для упорядочивания строк в каждой группе.SUM(), COUNT(), AVG() и т.п. Но есть и несколько специальных.ROW_NUMBER() выводит номер строки по порядку.PARTITION BY. В примере 2 на картинке ниже тот же набор разделён по полю name, а внутри каждой такой группы упорядочен по полю course.RANK() и DENSE_RANK() выводят ранг строки. Они отличаются от ROW_NUMBER() тем, что при равенстве результатов задают строкам одинаковые значения. При этом DENSE_RANK() продолжает нумерацию, например, 1,1,2,2,3. А RANK() использует следующий номер строки по порядку, оставляя разрывы в нумерации: 1,1,3,3,5. В примере 3 на картинке ниже приводится сравнение этих функций на том же наборе данных. Здесь использована сортировка всего набора по полю name, без разбиения на группы.ORDER BY внутри оконной функции никак не связано с выражением ORDER BY всего запроса. Оно влияет только на результаты оконной функции. В предыдущем примере мы могли бы добавить ORDER BY ко всему запросу и изменить порядок строк в запросе, но результаты функций ROW_NUMBER(), RANK() и DENSE_RANK() в строках не изменились бы.LAST_VALUE(course) на наборе данных из примера 2(последний по алфавиту курс для каждого студента), то будет выведено 3 строки:Jason Economics
Lucy Health Science
Martha Biology.LAG(), которая извлекает значения из предыдущих строк, и LEAD(), которая извлекает значения из последующих строк. В примере 4 на картинке ниже мы получаем значение суммы из предыдущего месяца с помощью функции LAG(sales,1). В функцию, помимо названия столбца, передаётся целое число, означающее количество строк, которые нужно отсчитать от текущей (в нашем случае 1). Для первой строки, очевидно, нет предыдущего значения, поэтому функция возвращает NULL.namespace HelloWorld;
public class Hello {
…
}
Можно иметь только одно пространство имён уровня файла, однако ничего не мешает вам создать вложенное пространство имён, заключив его код, как обычно, в фигурные скобки.[TypeConverter(typeof(X))]
использовать[TypeConverter<X>]
3. «Необработанные» строкиstring xml = """
<part number="1976">
<name>Windscreen Wiper</name>
<description>The "Windscreen wiper" automatically removes rain from your windscreen. It has a rubber <ref part="1977">blade</ref>, which can be ordered separately.</description>
</part>
""";
Если вам нужно использовать в тексте тройные кавычки, можете обозначить начало и конец строки четырьмя кавычками и т.д.dotnet list package --vulnerableКоманда выдаст список уязвимостей в пакетах верхнего уровня, версию пакета, в которой она исправлена и ссылку на рекомендации. Если вы хотите увидеть уязвимости в дочерних пакетах, используйте параметр
--include-transitive.
IDisposable между методами или в конструкторы. Возникает вопрос: я должен отвечать за вызов Dispose или это сделает кто-то другой? Когда мы вызываем Dispose из неправильного места, мы получаем незаметные, трудно поддающиеся диагностике ошибки.new, вы должны вызывать и Dispose. Если вы не вызывали new, вы не обязаны вызывать Dispose.void Save(IDbConnection conn) {
using(conn) {
//…
}
}
Разработчик пытается поступить правильно и очистить ресурсы после использования. Но теперь вызов Save имеет побочный эффект закрытия соединения. Это может привести к ошибке в другом месте:using(var cn = new SqlConnection("…")) {
Save(cn);
Update(cn); // ошибка
}
Мы получим исключение в Update, потому что функция Save закрыла наше соединение. Эта ошибка может быть довольно коварной: исключение будет выброшено из Update, поэтому поиск ошибки начнётся не в том месте. В зависимости от размера кодовой базы может потребоваться много времени, чтобы обнаружить, что обновление завершается ошибкой только при вызове после сохранения. Эта ошибка может тихо жить в кодовой базе в течение многих лет и проявиться, когда кто-то добавит вызов Update.IDisposable через внедрение зависимости (DI):public class Saver : IDisposable {
readonly IDbConnection _conn;
public Saver(IDbConnection conn) {
_conn = conn;
}
public void Save() {…}
public void Dispose() {
_conn.Dispose();
}
}
Опять же, разработчик пытается поступить правильно и очистить ресурсы после использования, но мы вводим неожиданные побочные эффекты в IDbConnection. Можно написать такой правильный код:using(var cn = new SqlConnection("…")) {
using(var sv = new Saver(cn)) {
sv.Save();
}
using(var upd = new Updater(cn)) {
upd.Update(); // ошибка
}
}
И опять трассировка стека приведет нас в Update. А если здесь ещё использовать контейнер DI для внедрения IDbConnection, то найти связь между методами сохранения и обновления может быть почти невозможно.IDisposable выглядит просто, но, как и большинство других вещей в жизни, дьявол в деталях. Мы можем защитить себя и свои программы:new, должен вызвать и Dispose.IDisposable и using дают нам инструменты для управления очисткой наших ресурсов, но это может противоречить ленивой оценке, которую мы получаем от ключевого слова yield.Console.WriteLine, чтобы увидеть, как проявляется ошибка. Нам понадобится реализация IDisposable и несколько вспомогательных функций, чтобы реализовать неявный вызов. Сначала рассмотрим рабочий код:startВсе операции расположены в правильном порядке, и мы очищаем наши ресурсы сразу после использования. Заменим вывод метода
connected
querying
dispose
result: 1
done
Query в строке 17 на yield return:startНаш запрос выполняется ПОСЛЕ очистки ресурсов! Заметьте, что в реальном приложении вы получите ошибку при обращении к несуществующему ресурсу. Что происходит?
connected
dispose
querying
result: 1
done
yield return, но компилятор «под капотом» проделал намного больше работы. Он создал класс с уникальным именем, реализующий IEnumerable<int>. Наш запрос к FakeResource возвращает экземпляр этого класса, но мы не выполняем собственно запроса, пока не начнёт исполняться цикл foreach. У Джона Скита есть отличный разбор всех внутренностей реализации. А подробнее про особенности выражения yield return, вы можете почитать на канале. Поищите посты по строке "Выражение yield return".using перед запуском нашего кода в Query(FakeResource).yield return и using могут быть в совершенно разных частях проекта. А чтобы столкнуться с этой ошибкой, нам достаточно хотя бы одного уровня косвенного доступа, и это довольно распространённое явление. При этом изменение на yield return само по себе выглядит невинно, и компилятор всем доволен.async и await; мы можем покинуть блок using, пока задача всё ещё хочет использовать наш IDisposable (см. этот пост).System.IDisposable - фундаментальный интерфейс, используемый в большинстве программ .NET. Его основная цель - предоставить механизм для высвобождения «неуправляемых» ресурсов: файловых потоков, подключений к базам данных, сетевых сокетов и т.д.public interface IDisposable {
void Dispose();
}
Что может быть проще? Кроме того, для него есть специальный синтаксис - оператор using:using(var stream=File.OpenText("…")) {
// неуправляемый ресурс stream
// живёт внутри этого блока
}
// здесь stream удаляется
Красиво и просто!IDisposable. Вот мои любимые ошибки.void, и готово! Но IDisposable обманывает. К нему предъявляются некоторые требования, которые нельзя выразить посредством простого объявления интерфейса:Dispose.IDisposable.IDisposable нарушает некоторые из наших фундаментальных предположений о полноте интерфейсов C#: недостаточно, чтобы компилятор был доволен, мы должны читать документацию, следить за подсказками статических анализаторов и удовлетворять любые их требования, которые компилятор не сможет проверить.IEquatable<T>, вы также должны переопределить базовые реализации Equals(Object) и GetHashCode().IComparable<T>, вы должны перегрузить op_GreaterThan, op_GreaterThanOrEqual и т.п.IFormattable, должен поддерживать формат «G» (общий)…IDisposable. А что насчёт использования чужих реализаций? Например, правильно ли SqlConnection использует шаблон Dispose? У нас нет другого способа узнать это, кроме как читать документацию.HttpClient. Обычно мы хотим освободить наши неуправляемые ресурсы как можно скорее. Реализуя IDisposable, HttpClient посылает нам сигнал о том, что он хочет находиться в блоке using:using(var client = new HttpClient()) {
// выполняем запрос
}
Но использование HttpClient таким образом всё испортит. В документации мы находим следующий перл:LogLevel.var userId = 1;Типичная проблема с этим кодом заключается в том, что вы можете случайно пропустить
var completed = true;
var someParamValue = "abc";
Uri baseAddress = new Uri("https://example.com/");
Uri apiUrl = new Uri(
$"/todos?userId={userId}&completed={completed}" +
$"&someParamValue={someParamValue}",
UriKind.Relative);
?, & или =. Кроме этого, страдает читабельность кода, особенно если параметров много.using Flurl;Помимо метода
string url = "https://example.com/"
.AppendPathSegment("todos")
.SetQueryParam("userId", userId)
.SetQueryParam("completed", completed)
.SetQueryParam("someParam", someParamValue);
SetQueryParam, существует и SetQueryParams, который принимает объект, любую коллекцию пар ключ-значение, кортеж или словарь. Методы расширения Flurl доступны как для String, так и для System.Uri. В любом случае результат легко конвертировать туда и обратно с помощью методов ToString() и ToUri():using Flurl;Помимо этого, Flurl предоставляет множество других полезных инструментов, вроде расширенного парсинга Url, различных вариантов кодирования добавляемых параметров и т.п. Загляните в документацию Flurl, чтобы узнать больше.
Uri url = "https://example.com/"
.AppendPathSegment("todos")
.SetQueryParams(new {
userId = userId,
completed = completed,
someParam = someParamValue
})
.ToUri();
ActionResult.[HttpPost("/authors")]
[SwaggerOperation(
Summary = "New Author",
Description = "Creates a new Author",
OperationId = "Author.Create",
Tags = new[] { "AuthorEndpoint" })
]
public override async
Task<ActionResult<CreateResult>>
HandleAsync([FromBody] CreateCommand req)
{
var author = new Author();
_mapper.Map(req, author);
await _repository.AddAsync(author);
var result =
_mapper.Map<CreateResult>(author);
return Ok(req);
}
Поскольку API Endpoints – это абстракция над веб-API, вы можете использовать Swashbuckle, NSwag или любое другое расширение веб-API вместе с конечными точками API и пользоваться всеми преимуществами стека веб-API, но с более модульным подходом, чем на основе MVC.public class HomeModule : CarterModule {
public HomeModule() {
Get("/", async (req, res) =>
await res.WriteAsync("Hello Carter!"));
}
}
Благодаря многочисленным примерам и документации проект легко изучить и поэкспериментировать, а также он предлагает интересный подход к созданию HTTP-приложений. OpenAPI встроен в Carter по умолчанию, поэтому создаваемые вами конечные точки могут автоматически отображаться в спецификации OpenAPI. Проект Carter также может быть объединён с традиционным веб-API и структурой приложения ASP.NET Core, поэтому вы можете использовать его вместе со знакомым промежуточным ПО и службами ASP.NET Core.httprepl -o <openapi-url>, чтобы подключиться к любому проекту веб-API, описанному по OpenAPI, и изучить его, используя знакомые команды, такие как ls или dir, и перемещаться по структуре API так же, как по дереву каталогов.--no-openapi в команде dotnet new webapi).Swashbuckle.CLI, который можно использовать для генерации спецификаций OpenAPI во время публикации в MSBuild или dotnet publish.HttpClient.3 1 4 1 5 9То ответ ниже удовлетворяет обоим условиям (результат отсортирован и той же длины):
3 3 3 3 3 3Хотя это соответствует спецификации, это определенно не то, что имелось в виду! Более того, этот пример основан на ошибке, взятой из реального производственного кода (к счастью, обнаруженной до того, как он был выпущен). Простое неверное нажатие клавиши или кратковременная невнимательность привели к тому, что результат заполнился первым элементом.
3 1 4 1 5 9Результат сортировки будет:
1 1 3 4 5 9Никакой другой ответ не годится!
WITH для определения «представлений в области действия оператора». Они не хранятся в схеме базы данных, а живут только в рамках текущего запроса. Это позволяет улучшить структуру запроса, не загрязняя глобальное пространство имен. Предложение WITH также известно как общее табличное выражение (CTE).WITH query1 (column1, …) AS
(SELECT … FROM table …)
SELECT * FROM query1;
WITH не является самостоятельной командой, за ним должен следовать SELECT. Запрос SELECT (и содержащиеся в нем подзапросы) могут ссылаться в своём блоке FROM на определённое в предложении WITH имя подзапроса.WITH может определять несколько имён подзапросов, разделяя их запятыми. Каждый из этих подзапросов может ссылаться на ранее определённые имена подзапросов:WITHВАЖНО! Имена подзапросов, определённые в предложении
query1 AS (SELECT …),
query2 AS (SELECT … FROM query1 …)
SELECT …
WITH скрывают таблицы или представления с тем же именем.WITH доступна во всех современных СУБД.WITH не только с запросами SELECT, но и с запросами на манипуляцию с данными (INSERT, UPDATE, DELETE).WITH-запрос как цель DML запроса, то есть создавать обновляемые представления.WITH.WITH. А при использовании выражения RETURNING, предложение WITH возвращает данные в основной запрос. Таким образом, например, можно сделать запрос к только что вставленным в таблицу записям:WITH added AS (Источник: https://modern-sql.com/feature/with
INSERT INTO table1 …
RETURNING *
)
SELECT * FROM added;