Как перезапустить файл pkg sqllocaldb

Как перезапустить файл pkg sqllocaldb

Данное руководство устарело. Актуальное руководство: Руководство по Entity Framework Core 7

Последнее обновление: 14.11.2020

В прошлой теме база данных изначально не существовала и создавалась автоматически в процессе запуска приложения в соответствии с определением классов моделей и класса контекста данных. Но нередко база данных для подключения уже имеется. Рассмотрим, как мы можем подключаться к уже существующей базе данных.

Для подключения к существующей базе данных создадим новый проект. Как и в прошлой теме это будет проект по типу Console App (.NET Core) , который назовем FirstApp.

Для работы с существующей БД MS SQL Server нам надо добавить два пакета:

• Microsoft.EntityFrameworkCore.SqlServer (представляет функциональность Entity Framework для работы с MS SQL Server)
• Microsoft.EntityFrameworkCore.Tools (необходим для создания классов по базе данных, то есть reverse engineering)

К примеру возьмем базу данных, созданную в прошлой теме. Эта база данных называется helloappdb.mdf и имеет одну таблицу Users с тремя столбцами Id, Name и Age.

Чтобы подключаться к базе данных, нам надо будет добавить в проект классы моделей, которые соответствуют определениям таблиц, и класс контекста данных, который соответствует БД. То есть в данном случае мы могли бы вручную добавить в проект классы моделей и класс контекста данных, как в прошлой теме.

Однако добавление классов вручную имеет свои недостатки. Так, если база данных имеет не одну, а множество таблиц, связанных различными ключами, то у нас может возникнуть проблема, как все эти отношения отобразить между класса на C#. Ну и кроме того, это просто долго и может занять некоторое время.

Для решения этих проблем в Entity Framework Core предусмотрена функция Reverse Engineering , которая позволяет автоматически создать все необходимые классы по базе данных. Чтобы воспользоваться этой функцией перейдем в Visual Studio к окну Package Manager Console . Его открыть можно, перейдя в меню Tools –> NuGet Package Manager –> Package Manager Console

Далее в Package Manager Console выполним следующую команду:

Scaffold-DbContext "Server=(localdb)\mssqllocaldb;Database=helloappdb;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer

Здесь в качестве параметра команде Scaffold-DbContext передается строка подключения с указанием сервера и названием базы данных.

После выполнения этой команды в проект будет добавлен класс Users:

public partial class User < public int Id < get; set; >public string Name < get; set; >public int Age < get; set; >>

И также будет добавлен класс контекста данных, который будет называться по имени базы данных плюс суффикс «Context»:

using System; using Microsoft.EntityFrameworkCore; using Microsoft.EntityFrameworkCore.Metadata; #nullable disable namespace FirstApp < public partial class helloappdbContext : DbContext < public helloappdbContext() < >public helloappdbContext(DbContextOptions options) : base(options) < >public virtual DbSet Users < get; set; >protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) < if (!optionsBuilder.IsConfigured) < optionsBuilder.UseSqlServer("Server=(localdb)\\mssqllocaldb;Database=helloappdb;Trusted_Connection=True;"); >> protected override void OnModelCreating(ModelBuilder modelBuilder) < OnModelCreatingPartial(modelBuilder); >partial void OnModelCreatingPartial(ModelBuilder modelBuilder); > >

И после генерации данных классов мы сможем работать с базой данных. Для этого изменим код класса Program:

using System; using System.Linq; namespace FirstApp < class Program < static void Main(string[] args) < using (helloappdbContext db = new helloappdbContext()) < // получаем объекты из бд и выводим на консоль var users = db.Users.ToList(); Console.WriteLine("Список объектов:"); foreach (User u in users) < Console.WriteLine($". - "); > > Console.ReadKey(); > > >

SQL Server Express LocalDB

LocalDB в Microsoft SQL Server Express — это компонент SQL Server Express, ориентированный на разработчиков. Он доступен в SQL Server Express с дополнительными службами.

Установка LocalDB копирует минимальный набор файлов, необходимых для запуска ядро СУБД SQL Server. После установки LocalDB вы можете установить соединение с помощью специальной строки подключения. При подключении необходимая инфраструктура SQL Server автоматически создается и запускается, что позволяет приложению использовать базу данных без сложных задач конфигурации. Средства разработчика позволяют использовать ядро СУБД SQL Server для создания и проверки кода Transact-SQL без обязательств по управлению полноценным экземпляром сервера SQL Server.

Установочный носитель

LocalDB — это компонент, выбираемый во время установки SQL Server Express и доступный при загрузке с носителя. Если вы скачиваете носитель, выберите Express Advanced или пакет LocalDB .

• SQL Server Express 2022
• SQL Server Express 2019
• SQL Server Express 2017
• SQL Server Express 2016

Клиенты Visual Studio 2019 и 2022 должны установить SQL Server Express 2019.

Установщик SqlLocalDB.msi LocalDB доступен на установочном носителе для всех выпусков, кроме Express Core. Он находится в папке \_ENU_LP\x64\Setup\x64 . LCID — это идентификатор языкового стандарта или код языка. Например, LCID = 1033 означает языковой стандарт en-US (английский, США).

Кроме того, LocalDB можно установить с помощью Visual Studio Installer в составе рабочей нагрузки Хранение и обработка данных, рабочей нагрузки ASP.NET и веб-разработка или как отдельный компонент.

Установка LocalDB

Для установки LocalDB используйте мастер установки или программу SqlLocalDB.msi . LocalDB подходит при установке SQL Server Express LocalDB.

Выберите LocalDB на странице Выбор компонентов или «Общие компоненты» во время установки. Для каждой основной версии SQL Server ядро СУБД может быть только одна установка двоичных файлов LocalDB. Можно запустить несколько ядро СУБД процессов и использовать одни и те же двоичные файлы. Экземпляр SQL Server ядро СУБД запущен, так как LocalDB имеет те же ограничения, что и SQL Server Express.

Экземпляр SQL Server Express LocalDB управляется с помощью служебной SqlLocalDB.exe программы. SQL Server Express LocalDB следует использовать вместо функции экземпляра пользователя SQL Server Express, которая не рекомендуется.

Description

Программа установки LocalDB использует программу SqlLocalDB.msi для установки необходимых файлов на компьютере. После установки LocalDB — это экземпляр SQL Server Express, который может создавать и открывать базы данных SQL Server. Файлы системной базы данных, как правило, хранятся в каталоге AppData, который обычно скрыт. Например, C:\Users\\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\LocalDBApp1\ . Файлы пользовательской базы данных хранятся в месте, указанном пользователем, как правило, в папке C:\Users\\Documents\ .

Дополнительные сведения об API LocalDB см. в разделе Справочник по SQL Server Express LocalDB.

Служебная программа SqlLocalDB позволяет создавать новые экземпляры LocalDB, запускать и останавливать работу экземпляров, а также использовать функции для управления LocalDB. Дополнительные сведения о служебной программе SqlLocalDB см. в разделе Программа SqlLocalDB.

Параметры сортировки экземпляра для LocalDB заданы SQL_Latin1_General_CP1_CI_AS и не могут быть изменены. Параметры сортировки на уровне базы данных, на уровне столбца и на уровне выражения поддерживаются обычным образом. Автономные базы данных следуют правилам метаданных и параметрам сортировки tempdb , определенным Contained Database Collations.

Ограничения

• LocalDB не может управляться удаленно с помощью SQL Server Management Studio.
• LocalDB не может быть подписчиком слияния реплика tion.
• LocalDB не поддерживает FILESTREAM.
• Для LocalDB разрешены только локальные очереди компонента Service Broker.
• Экземпляр LocalDB, принадлежащий встроенным учетным записям, таким как NT AUTHORITY\SYSTEM , может иметь проблемы с управлением из-за перенаправления файловой системы Windows. Вместо этого используйте в качестве владельца обычную учетную запись Windows.

Автоматические и именованные экземпляры

LocalDB поддерживает два типа экземпляров: автоматические и именованные.

• Автоматические экземпляры LocalDB являются общедоступными. Они создаются и обслуживаются автоматически и могут использоваться любым приложением. Для каждой версии LocalDB, установленной на компьютере пользователя, существует один автоматический экземпляр LocalDB. Автоматические экземпляры LocalDB обеспечивают удобное управление экземплярами. Нет необходимости создавать экземпляр. Он просто работает. Эта функция упрощает установку приложения и его перенос на другой компьютер. Если на целевом компьютере установлена указанная версия LocalDB, то там также будет доступен автоматический экземпляр LocalDB для этой версии. Автоматические экземпляры LocalDB именуются по специальному шаблону, принадлежащему зарезервированному пространству имен. Автоматические экземпляры предотвращают конфликты имен с именованными экземплярами LocalDB. Имя автоматического экземпляра . MSSQLLocalDB
• Именованные экземпляры LocalDB являются закрытыми. Они принадлежат одному приложению, которое отвечает за создание экземпляра и управление им. Именованные экземпляры обеспечивают изоляцию от других экземпляров и способствуют повышению производительности за счет снижения уровня конфликта за ресурсы с другими пользователями базы данных. Необходимо явно создавать именованные экземпляры с помощью API управления LocalDB или неявно с помощью app.config файла управляемого приложения (хотя управляемое приложение также может использовать API при необходимости). Каждый именованный экземпляр LocalDB имеет связанную с ним версию LocalDB, которая указывает на соответствующий набор двоичных файлов LocalDB. Имя экземпляра LocalDB имеет тип данных sysname и может содержать до 128 символов. (Это имя экземпляра отличается от обычных именованных экземпляров SQL Server, что ограничивает имена обычных имен NetBIOS 15 символов ASCII.) Имя экземпляра LocalDB может содержать любые символы Юникода, которые являются законными в имени файла. Именованный экземпляр, в котором используется имя автоматического экземпляра, становится автоматическим экземпляром.

Разные пользователи одного и того же компьютера могут иметь экземпляры с одинаковыми именами. Каждый экземпляр запускается в качестве соответствующего пользователя в собственном процессе.

Общие экземпляры LocalDB

В LocalDB поддерживается общий доступ к экземплярам, если нескольким пользователям компьютера требуется доступ к одному экземпляру LocalDB. Владелец экземпляра может разрешить другим пользователям компьютера подключаться к своему экземпляру. Общими могут быть как автоматические, так и именованные экземпляры LocalDB. Для организации общего доступа к экземпляру LocalDB пользователь должен указать его общее имя (псевдоним). Поскольку общее имя видно всем пользователям компьютера, то оно должно быть уникальным на этом компьютере. Общее имя экземпляра LocalDB имеет тот же формат, что и именованный экземпляр LocalDB.

Только администратор компьютера может создавать общие экземпляры LocalDB. Администратор или владелец общего экземпляра LocalDB может отменить общий доступ к экземпляру LocalDB. Предоставление и отмена общего доступа к экземпляру LocalDB выполняется с помощью методов LocalDBShareInstance и LocalDBUnShareInstance API LocalDB либо с помощью соответствующих параметров служебной программы SqlLocalDB .

Запуск LocalDB и подключение к LocalDB

Подключение к автоматическому экземпляру

Самым простым способом использования LocalDB является подключение к автоматическому экземпляру, владельцем которого является текущий пользователь, с использованием строки подключения Server=(localdb)\MSSQLLocalDB;Integrated Security=true . Для подключения к определенной базе данных. используя имя файла, подключитесь с помощью строки подключения, аналогичной Server=(LocalDB)\MSSQLLocalDB;Integrated Security=true;AttachDbFileName=D:\Data\MyDB1.mdf .

Соглашение об именовании и строка подключения формата LocalDB в SQL Server 2014 (12.x). Ранее именем экземпляра был один символ v, за которым следует LocalDB и номер версии. Начиная с SQL Server 2014 (12.x), этот формат имени экземпляра больше не поддерживается, а вместо него следует использовать строка подключения упоминание ранее.

При первом подключении пользователя компьютера к LocalDB необходимо создать и запустить автоматический экземпляр. Дополнительное время, необходимое для создания экземпляра, может стать причиной того, что попытка соединения завершится с ошибкой истечения времени ожидания. В этом случае подождите несколько секунд до завершения процесса создания экземпляра, а затем подключитесь снова.

Создание именованного экземпляра и подключение к нему

Помимо автоматических экземпляров, LocalDB также поддерживает именованные экземпляры. SqlLocalDB.exe Используйте программу для создания, запуска и остановки именованного экземпляра LocalDB. Дополнительные сведения см. в SqlLocalDB.exe разделе «Служебная программа SqlLocalDB».

REM Create an instance of LocalDB "C:\Program Files\Microsoft SQL Server\160\Tools\Binn\SqlLocalDB.exe" create LocalDBApp1 REM Start the instance of LocalDB "C:\Program Files\Microsoft SQL Server\160\Tools\Binn\SqlLocalDB.exe" start LocalDBApp1 REM Gather information about the instance of LocalDB "C:\Program Files\Microsoft SQL Server\160\Tools\Binn\SqlLocalDB.exe" info LocalDBApp1 

Последняя строка в предыдущем примере кода возвращает сведения, аналогичные следующей таблице.

Категория	Значение
Имя	LocalDBApp1
Версия
Общее имя	«»
Ответственное лицо	«»
Автоматическое создание	No
State	Running
Время последнего запуска
Имя канала экземпляра	np:\\.\pipe\LOCALDB#F365A78E\tsql\query

Если приложение использует версию .NET до 4.0.2, необходимо подключиться непосредственно к именованной каналу LocalDB. Значение «Имя канала экземпляра» — это именованный канал, который прослушивает экземпляр LocalDB. Часть имени канала экземпляра, следующая после LOCALDB#, будет изменяться при каждом запуске экземпляра LocalDB. Чтобы подключиться к экземпляру LocalDB с помощью SQL Server Management Studio, введите имя канала экземпляра в поле имени сервера Подключение в диалоговом окне ядро СУБД. Можно установить соединение с экземпляром LocalDB из пользовательской программы с использованием строки подключения, аналогичной SqlConnection conn = new SqlConnection(@»Server=np:\\.\pipe\LOCALDB#F365A78E\tsql\query»); .

Подключение к общему экземпляру LocalDB

Чтобы подключиться к общему экземпляру LocalDB, добавьте \.\ (backslash + dot+ backslash) в строка подключения, чтобы ссылаться на пространство имен, зарезервированное для общих экземпляров. Например, чтобы подключиться к общему экземпляру LocalDB с именем AppData , укажите (localdb)\.\AppData в строке подключения. Пользователь, подключающийся к общему экземпляру LocalDB, которому он не владеет, должен иметь имя входа проверки подлинности Windows или проверки подлинности SQL Server.

Устранить неполадки

Способы устранения неполадок в работе LocalDB см. в статье Troubleshoot SQL Server 2012 Express LocalDB (Устранение неполадок в работе SQL Server 2012 Express LocalDB).

Разрешения

SQL Server Express LocalDB — это экземпляр, созданный пользователем для самостоятельного использования. Любой пользователь компьютера может создать базу данных с помощью экземпляра LocalDB, сохранив файлы в своем пользовательском профиле и запустив процесс со своими учетными данными. По умолчанию доступ к экземпляру LocalDB имеет только его владелец. Данные, содержащиеся в LocalDB, защищены средствами файловой системы. Если файлы пользовательской базы данных хранятся в общем расположении, база данных может быть открыта любым пользователем с доступом к файловой системе в этом расположении с помощью экземпляра LocalDB, которому они принадлежат. Если файлы базы данных хранятся в защищенном месте, например в папке пользовательских данных, то базу данных может открыть только сам пользователь, а также администратор, обладающий правами доступа к данной папке. Файлы LocalDB могут быть одновременно открыты только одним экземпляром LocalDB.

LocalDB всегда запускается в контексте безопасности пользователя. Это означает, что LocalDB никогда не будет запускаться с учетными данными группы локальных администраторов. То есть доступ ко всем файлам базы данных, используемыми экземпляром LocalDB, возможен по учетной записи их владельца-пользователя Windows, не учитывая принадлежности к группе локальных администраторов.

Следующие шаги

DataGrip 2021.3: Aggregate view в редакторе, табличное представление узлов дерева БД, новое окно сравнения БД

В этом посте мы расскажем, что нового в свежем релизе DataGrip 2021.3. Если вы работаете с базами данных в других IDE JetBrains, то этот пост и для вас тоже.

Редактор данных

Агрегаты

Как в Excel и Google таблицах: мы добавили возможность отображать панель с агрегированными данными для диапазона ячеек в редакторе данных. Это помогает работать с данными без необходимости писать дополнительные запросы.

Выберите диапазон ячеек, щелкните правой кнопкой мыши и выберите Show Aggregate View.

• Aggregate и Value находятся на одной панели, для каждого отдельная вкладка. Панель можно переместить в нижнюю часть редактора данных.
• Вы можете убрать из представления ненужные агрегаты в меню под шестеренкой.
• Как и экстракторы, агрегаты это скрипты. Мы добавили девять готовых агрегатов, но вы можете создавать свои собственные и делиться ими с коллегами.
• Скрипты агрегатов и экстракторы взаимозаменяемы. Экстрактор, который вы использовали для получения одного значения, теперь можно скопировать в папку Aggregators и использовать для агрегатов. Папка находится в разделе Scratches and consoles / Extensions / Database Tools and SQL, рядом с папкой Extractors.Агрегированное значение отображается в строке состояния — вы можете выбрать, какое именно вам нужно (сумма, минимальное/максимальное значение, среднее значение, медиана, и т. д.).

Табличное представление узлов дерева базы данных

Нажмите F4 на любом узле схемы, чтобы увидеть его содержимое в виде таблицы. Например, вы можете получить представление всех таблиц в схеме:

Или просмотреть столбцы в виде таблицы:

В табличном представлении можно скрывать/показывать столбцы, экспортировать данные в разных форматах и искать по текстовым вхождениям. Здесь также работают шорткаты:

• Ctrl / Cmd + B покажет DDL.
• F4 покажет данные.
• Alt / Opt + Shift + B подсветит объект в дереве базы данных.

Независимое разделение редактора данных

В DataGrip можно разделить редактор данных, но раньше фильтрация и сортировка были синхронизированы, а это неудобно.

Теперь, если вы разделите редактор и откроете одну и ту же таблицу, два окна редактора данных будут независимыми. Можно фильтровать и сортировать данные параллельно.

Пользовательские шрифты

Вы можете выбрать шрифт для отображения данных в разделе Database | Data views | Use custom font.

Навигация по внешним ключам на основе нескольких значений

Теперь в редакторе данных теперь можно выбрать сразу несколько значений и перейти к соответствующим данным по внешним ключам.

Настройка сортировки по умолчанию

Вы можете указать, какой метод будет использоваться по умолчанию для сортировки таблиц. При выборе сортировки на стороне клиента DataGrip не будет выполнять дополнительные запросы и отсортирует только текущую страницу. Чтобы выбрать сортировку на стороне сервера, перейдите в раздел Database | Data views | Sorting | Sort via ORDER BY.

Режим отображения бинарных данных

16-байтовые данные теперь по умолчанию отображаются как UUID. Вы можете настроить способ отображения бинарных данных в контекстном меню столбца.

[MongoDB] Автодополнение для filter <> and sort <>

При фильтрации данных в коллекциях MongoDB теперь работает автодополнение.

Хранение базы данных в VCS

Соотнесение источников данных на основе DDL с реальными

В прошлом релизе появилась возможность генерировать источник данных на основе DDL из реального источника данных. А теперь вы можете больше: соотносить источник данных DDL с реальным, сравнивать и синхронизировать их.

Напоминаем, что источник данных на основе DDL — это виртуальный источник данных, схема которого основана на SQL-скриптах. Сохраняя DDL- файлы в системе контроля версий, вы сохраняете в ней схему вашей базы данных.

В настройках конфигурации данных появилась новая вкладка DDL Mapping, где можно соотнести DDL-источники данных с реальными.

Новое окно сравнения баз данных

Чтобы сравнить и синхронизировать ваш источник данных на основе DDL с реальным, используйте контекстное меню и выберите Apply from… или Dump to… в подменю DDL Mapping.

Окно на правой панели показывает, какой результат вы получите после выполнения синхронизации.

Что означают цвета:

• Зеленый курсив: объект будет создан.
• Серый: объект будет удален.
• Синий: объект будет изменен.

На вкладке Script preview отображается скрипт миграции, который можно запустить из этого окна или открыть в новой консоли. Выполнив скрипт, вы преобразуете базу данных справа (целевую) в идентичную базе данных слева (исходной).

Кроме вкладки Script preview, на нижней панели есть еще две вкладки: Object Properties Diff и DDL Diff. Они показывают разницу между конкретными версиями объекта в исходной и целевой базах данных.

Напоминаем: если вы хотите просто сравнить две схемы или объекты, выберите их и нажмите Ctrl / Cmd + D.

Важно! Окно сравнения/миграции все еще находится в разработке. Каждая база данных имеет свои особенности, поэтому некоторые объекты могут отображаться как разные, хотя на самом деле они идентичны. Если вы столкнулись с такой ошибкой, создайте тикет в нашем трекере.

Файловые операции

Теперь любые файловые операции можно совершать с объектами в источниках данных на основе DDL. Например, из проводника базы данных вы можете удалять, копировать и коммитить файлы, связанные с объектами схемы.

Автосинхронизация

Раньше автосинхронизация была включена по умолчанию: источники данных на основе DDL автоматически обновлялись при изменениях соответствующих файлов. Теперь вы можете отключить эту опцию: изменения в исходных файлах не будут автоматически отражаться в DDL источниках данных. Тогда, чтобы применить их, нужно будет нажать Refresh.

Схемы и базы данных по умолчанию

В панели Default schemas/databases можно указать имена баз данных и схем, которые будут отображаться для источника данных DDL. Скрипты DDL, как правило, не содержат имен, поэтому DataGrip автоматически создаст для баз данных и схем одноразовые названия, которые вы указали.

Соединение

Предупреждение о лишних пробелах

Если при тестировании соединения в строках кроме User и Password обнаружатся лишние пробелы, DataGrip предупредит вас об этом.

[SQL Server] LocalDB как выделенный источник данных

Добавили в список драйверов выделенный драйвер SQL Server LocalDB.

• Подключение LocalDB проще найти.
• Достаточно один раз указать путь к исполняемому файлу в настройках драйвера, и он будет применен для всех источников данных.

[Oracle, SQL Server] Аутентификация Kerberos

Для Oracle и SQL Server работает аутентификация Kerberos. Используйте команду kinit, чтобы получить исходный билет для принципала — DataGrip будет применять его при выборе опции Kerberos.

[Oracle, IBM Db2] Включение DBMS_OUTPUT

Теперь на вкладке Options можно по умолчанию включать DBMS_OUTPUT для новых сеансов.

Кнопка More options

Если вам нужно особым образом настроить соединение, нажмите кнопку More Options. Вы сможете добавить поля Schema и Role для соединений Snowflake, а также настроить SSH и SSL.

Expert options

Некоторые опции созданы для решения конкретных проблем: неправильно определяется тип базы данных, не работает или тормозит интроспекция и пр. Мы убрали такие опции в список Expert options на вкладке Advanced, чтобы пользователи не активировали их случайно.

• Включение интроспектора JDBC. Если это чем-то помогает, это не нормально. Пожалуйста, напишите нам, прежде чем включать эту опцию!
• Oracle: отключение инкрементальной интроспекции, выборки LONG значений и интроспекции серверных объектов .
• SQL Server: отключение инкрементальной интроспекции.
• PostgreSQL (и аналогичные БД): отключение инкрементальной интроспекции, запрет использования xmin в запросах к pgdatabase.
• SQLite: регистрация функции REGEXP.
• MYSQL: использование SHOW / CREATE в исходном коде.
• Clickhouse: автоматическое назначение sessionid.

Интроспекция

[Oracle] Уровни интроспекции

Пользователи Oracle сталкиваются с проблемой: если у них много баз данных и схем, интроспекция в DataGrip занимает много времени.

Интроспекция — это процесс получения метаданных базы данных: имена объектов, исходный код и др. DataGrip использует эти данные для автодополнения кода, навигации и поиска.

Системные каталоги Oracle работают довольно медленно, но мы поняли, что для повседневной работы (и даже для эффективного автодополнения кода) нет необходимости загружать всю информацию об объектах. Во многих случаях имен объектов базы данных достаточно. Поэтому мы разделили интроспекцию для баз данных Oracle на три уровня:

Уровень 1. Получаем метаданные только об именах всех поддерживаемых объектов, кроме имен столбцов индекса и приватных переменных пакета (package).

Уровень 2: Интроспектируем все, кроме исходников.

Уровень 3: Интроспектируем все.

Интроспекция происходит быстрее всего на первом уровне и медленнее всего на третьем.

Уровень интроспекции меняется в контекстном меню:

Уровень интроспекции может быть установлен либо для схемы, либо для всей базы данных. Схемы наследуют свой уровень от базы данных, но его можно установить независимо.

Иконка-пилюля рядом с иконкой источника данных показывает уровень интроспекции. Чем больше наполнена пилюля, тем выше уровень. Синий цвет иконки означает, что уровень установлен напрямую, а серый — что он унаследован.

[SQL Server, Oracle] Соотнесение связанных серверов и ссылок на базы данных с источниками данных

Теперь вы можете соотнести связанный сервер из SQL Server (linked server) или ссылку на базу данных в Oracle (db-links) с любым источником данных.

Если вы связали внешние объекты с источниками данных, будет работать автодополнение в запросах, использующих этот объект.

[PostgreSQL] Возможность скрыть системные схемы и базы данных шаблонов

Раньше список схем не показывал системные схемы (pg_toast, pg_temp и др.) и шаблоны баз данных. Мы добавили возможность отображать их: вы найдете эти настройки на вкладке Schemas.

[Snowflake] Поддержка потоков

Теперь в проводнике базы данных помимо таблиц и представлений отображаются потоки.

[ClickHouse] Распределенные таблицы

В проводнике баз данных появилась отдельная папка для распределенных таблиц.

Консоль запросов

Проверка логических выражений

Один из наших пользователей написал в Твиттере о неприятной ситуации: он выполнил запрос UPDATE в производственной базе данных с условием WHERE id – 3727 (вместо =) и обновил миллионы записей!

Мы тоже удивились, что в MySQL такое возможно, и сразу добавили проверку логических выражений в предложениях WHERE и HAVING.

Если выражение не совсем похоже на логическое, DataGrip выделит его желтым цветом и предупредит перед выполнением запроса. Это работает для ClickHouse, Couchbase, Db2, H2, Hive / Spark, MySQL / MariaDB, Redshift, SQLite и Vertica. В других базах данных это будет отмечено как ошибка.

Создание табличных функций из запроса

Теперь команда Extract Routine умеет создавать табличные функции на основе SQL-запросов. Для этого выделите запрос, откройте меню Refactor и выберите опцию Extract Routine. Поддерживается для Db2, SQL Server, Postgres, Greenplum и Snowflake.

Подсказка о кратности JOIN

Появилась встроенная подсказка, показывающая количество узлов в условии для JOIN. Есть три основных опции: one-to-one, one-to-many, and many-to-many (подробнее об этом в статье на Wiki). Можно выключить подсказку в Preferences | Editor | Inlay Hints | Join cardinality.

[MongoDB] Автодополнение имен баз данных

Автодополнение работает для названий баз данных при использовании getSiblingDB, а при использовании getCollection — для имен коллекций. Кроме того, автодополнение работает, если используются имена полей из коллекции, определенной с помощью getCollection.

Окно инструментов Services

Результаты без временных меток

Нас просили убрать временные метки в панели Output: они больше не отображаются по умолчанию. Если вы хотите вернуть как было, измените настройку в Database | General | Show timestamp for query output.

Новые настройки управления поведением панели Services

Если вы используете панель Services в оконном режиме, по умолчанию оно всегда скрыто за IDE. Мы добавили настройку, которая передает фокус окну при каждом запуске запроса — оно будет появляться, как только запрос выполнится.

Кроме того, если вам не нравится, что после выполнения долгого запроса в панели Services активируется соответствующая вкладка, установите флажок Activate Services output pane for selected query console only.

Import/Export

Новый интерфейс для импорта данных

Мы улучшили импорт .csv-файлов и копирование наборов данных:

• Вы можете выбрать существующую таблицу или создать новую.
• В окне можно поменять схему для направления импорта. Раньше открывалось отдельное окно для выбора схемы, теперь его нет.
• Выбор целевой схемы сохраняется по умолчанию. Если вы постоянно импортируете в одну и ту же схему, вам не придется указывать её заново каждый раз.

Автоматическое определение первой строки как заголовка

При открытии или импорте .csv-файла DataGrip автоматически определяет первую строку как заголовок с названиями столбцов.

Автоматическое определение типов столбцов в .csv-файлах

DataGrip теперь определяет типы столбцов в .csv-файлах. Теперь можно сортировать данные по числовым значениям. Раньше они определялись как текст, и это мешало сортировке.

Прочее

Новая панель Bookmarks

Раньше у нас было два похожих понятия — Favorites и Bookmarks. Разница между ними была не очень понятна, и мы решили оставить только Bookmarks. Мы поменяли логику для этой функции и сделали для закладок отдельную панель.

Теперь в новой панели Bookmarks будут все объекты или файлы, которые вы отметите как важные (F3 в macOS или F11 в Windows / Linux).

На этом все! Напоминаем, что у DataGrip есть свой канал в Телеграме, там можно задавать вопросы и делиться опытом. А про баги лучше сразу в трекер, чтобы не потерялись. Спасибо за внимание!

Ваша команда DataGrip
The Drive to Develop

Оригинал статьи опубликован на Habr.com.

Разработчики в борьбе за эффективность программиста, команды, команд

Сегодня мы хотели бы обсудить один очень важный аспект эффективной работы — повторное использование.

Речь пойдет, конечно, о коде.

Рутинном, который не хочется писать дважды, а тем более трижды. Инфраструктурном, который приходится писать от проекта к проекту. Гениальном, который просто выражает собой отличную идею и которым грех не дать попользоваться другим.

Да и давайте признаемся — все мы любим писать “фреймворки”, которыми пользуемся потом сами и которыми пользуются другие. Это добавляет немного куража нашей повседневной деятельности.

И тут автор ловит себя на том, что поступает неправильно, начиная описывать ситуации — все и так понимают, о чем речь. А описать нужно технологии и процесс. Поэтому давайте просто остановимся на абстрактной мысли, что внезапно нашлось много кода, который может быть полезен коллегам и его хорошо бы сделать легкодоступным. Также примем во внимание вторую, куда менее приятную, мысль, что в “зрелых” проектах можно найти большое количество copy-paste кода, значительно понижающего сопровождаемость. Да и работу над такими проектами приятной назвать трудно. И с этим надо что-то делать.

И мы решили с этим что-то делать.

Путь, пройденный нами, оказался не таким сложным, мы можем посоветовать повторить его другим, ибо потраченное время себя окупает. А поскольку в какой-то момент этот путь стал интересным и даже забавным, мы решили поделиться своим опытом.

Ну да хватит предисловий.

1. Как развернуть корпоративный nuget-сервер (основы nuget мы опустим, полагая, что большинство читателей знает, что это такое).
2. Как развернуть корпоративный symbol-сервер, интегрированный с nuget.
3. Почему одного nuget-сервера недостаточно для построения эффективного процесса.
4. Также заранее обозначим темы для второй части, которую мы с удовольствием изготовим, если данная тема найдет своих читателей:
5. Что такое SandCastle и с чем его едят.
6. Как настроить continuous integration, чтобы автоматизировать всё нами содеянное.
7. Несколько мыслей по поводу (само)организации.

Разворачиваем корпоративный nuget-сервер.

Итак, nuget — это здорово и весело. Это не просто новый инструмент, повышающий продуктивность, это новый подход, новый образ мыслей. Почти такой же полезный, как здоровое питание и утренняя гимнастика. Значит надо использовать.

1. Простое развертывание ленты без UI и плюшек. Для этого варианта достаточно создать MVC application и установить сервер nuget, скачав nuget-пакет (такая вот рекурсия).
2. Второй вариант создан для чуть менее ленивых, но зато он с UI и плюшками. Для него необходимо скачать исходники и собрать их согласно инструкции с той же страницы. После этого, нажав Ctrl+F5, мы должны увидеть (почти) полный аналог официальной ленты.

Собственно, на этом и всё — процесс чрезвычайно прост. Однако есть несколько моментов, не описанных в документации, которые проявились у нас и которые могут быть полезны другим:

1. IIS express. Вариант работы на IIS express с использованием localdb трудно рассматривать как production ready по целому ряду причин. Поэтому мы перенесли нашего новорожденного на полнофункциональный сервер IIS. Благо, сложностей с этим никаких не возникает. Просто идем во вкладку properties проекта “Website” и снимаем галку “Use IIS Express” в разделе “Web”. Visual Studio моментально среагирует на такие перемены — предложит создать Virtual Directory и сменить Connection Strings в web.config с localdb на SQL express.

2. Database Migrations. Nuget использует для доступа к данным Entity Framework и активно пользуется механизмом Database Migrations. В руководстве к развертыванию есть шаг № 4 — создание БД при помощи танцев с саблями вокруг порядка открывания вкладок в студии. На самом деле всё проще. Достаточно просто указать имя проекта, в котором хранятся migrations, при обновлении через консоль. И никаких танцев:

3. Настройки безопасности. В руководстве не описаны моменты, касающиеся настроек безопасности (хотя они были в устаревшем руководстве). Видимо, предполагается что ставит всё безоговорочный админ и крутиться всё будет под его же учеткой. Если это не так, то нам нужно:

• a. Дать права на запись в папку “AppData” приложения. Туда будут складываться nuget-пакеты. Даем права аккаунту, под которым крутится AppPool-приложения. На случай, если в настройках IIS стоит ApplicationPoolIdentity, а не конкретная учетная запись, даем права группе IIS_IUSRS.
• b. По тем же принципам даём права на доступ к БД в SQL.
• c. Можно после регистрации дать себе же роль админа. Для этого после стандартной регистрации через UI вставляем запись в таблицу dbo.UserRoles, поглядев Id роли в таблице dbo.Roles. После этого по адресу “/admin” вам станет доступна админка cо всякими плюшками и букмарклетом glimpse.

4. GalleryOwner. Есть смысл поменять на реальные настройки пункта “Gallery.GalleryOwner” в web.config. От него будут рассылаться письма при регистрации. А можно и вовсе отключить эту рассылку. И обязательно пропишите актуальный SiteRoot.

5. В файле stats.js есть функция getStats. На момент написания данной статьи ее вызов приводил к ошибке на главной странице.

Причина кроется в том, что в локальной версии nuget статистика отключена. На данный момент она предназначена только для облачной версии.

Вы можете создать свою реализацию IStatisticsService или просто отключить данный вызов. Мы выбрали второй путь.

На этом, собственно, всё. Теперь у нас есть nuget-сервер с галереей и пакетами.

Но что, если в наш пакет (dll-ку из него) закрался баг? Или разработчик просто хочет понять, что делает наша функция “DoStuff”? Очевидно, библиотеку нужно дебажить. Но не так-то это просто, когда у нас в распоряжении есть только dll. Именно поэтому nuget умеет собирать не только пакеты библиотек, но и symbol-пакеты.

А мы идем учиться собирать свой собственный symbol server

В качестве решения для поддержки отладки мы решили использовать SymbolSource, поскольку он настолько хорошо дружит с nuget, что тот его поддерживает как symbol-сервер по умолчанию.

Тут мы сделаем небольшое отступление и расскажем, как это всё работает.

При создании nuget-пакета через команду nuget pack мы можем указать флаг “–Symbols”. В результате nuget создает, помимо стандартного пакета с библиотечкой, ещё пакет .symbols.nupkg, который будет содержать в себе pdb-файл и исходники. Потом этот пакет можно разместить на сервере SymbolSource, который проиндексирует pdb-файл и разместит у себя во внутреннем каталоге исходники проекта. Далее в Visual Studio настраивается доступ к symbol серверу, и при необходимости она загрузит с сервера pdb-файл и исходники. Так и становится возможной отладка.

Но, коли уж библиотеки мы не решились складывать в публичный feed, то про исходники и говорить нечего. В принципе, SymbolSource даёт возможность завести приватную ленту. Но также он поддерживает Community версию, позволяющую развернуть свой внутренний сервер. По целому ряду причин мы решили пойти последним путём.

И тут начались приключения…

По задумке авторов, развернуть свой symbol сервер задача почти такая же простая, как и развернуть свой nuget feed — создаем MVC-приложение, качаем nuget-пакет, даём права на папки “App_Data” и “Data” — всё работает.

Ах да, есть одно дополнительное требование — необходимо поставить Debugging Tools for Windows и прописать путь к ним в web.config:

Собственно, так мы и сделали — загрузили версию 1.3.2 SymbolServer-а, поставили, настроили, увидели волшебный экран.

Диагностику запустили — всё хорошо. Настроили Visual Studio в точности по инструкции.

Но Debug не работает…

Проблема нашлась достаточно быстро – сервис не сохранял в каталог “Data” исходники при загрузке symbol-пакета. Повозившись какое-то время с настройками IIS, мы поняли, что проблема в другом, и занялись отладкой.

Именно. Отладка сервера SymbolSource при помощи сервера SymbolSource.

Причина проблемы тоже нашлась достаточно быстро, и поначалу показалась даже смешной. В классе ManagedSourceExtractor есть метод IsTemporaryCompilerFile, возвращающий, как понятно из названия, признак, является ли некий файл временным файлом компилятора. И в этом методе стоял лишний оператор логического отрицания. То есть этот метод сообщал, что темповыми являлись как раз те файлы, которые ими не являлись. Так один лишний символ сломал весь сервер.

Ну что поделаешь… Посмеялись, форкнули исходники, поправили, собрались делать pull request. И тут мы обнаруживаем, что аналогичный request уже есть, причём создан достаточно давно. Да и пакет версии 1.3.2 выпущен уже два месяца как, а вот версия пакета с фиксом не выпущена до сих пор. Вот это уже было не так смешно. Точнее, совсем не смешно.

На какое-то время мы даже задумались, стоит ли вообще использовать этот сервер или лучше поискать другой. Но положительный предыдущий опыт использования… И разработчики nuget сделали его сервером по умолчанию, значит доверяют. И пакет версии 1.3.1 отлично работает. В итоге мы решили запустить всё на поправленных исходниках. Для этого дополнительно скопировали настройку из “Web.config.transform” в “Web.config”, поскольку при локальной сборке transform не выполняется:

Теперь готово и еще и работает как надо. И тут настало время подумать о том,

Почему одного nuget-сервера недостаточно для построения эффективного процесса (beta).

А недостаточно его по очень простой причине: nuget, как он есть, это доступный всей компании сервер.

Значит, в него нельзя класть пакеты, которые могут оказаться нестабильными. Но когда разработка конечных проектов потребовала изменения сборок, размещаемых в nuget, то внести изменения так, чтобы заработало сразу, задача из разряда “пишем код без багов”.

Различных приемов и приседаний, чтобы как-то работать с одним сервером, можно найти множество. Например, подменять ручками dll-ки в папке “packages” конечного проекта, а в nuget публиковать только когда уже всё готово. Но мы же делаем это всё, чтобы жизнь стала проще, а не наоборот. Поэтому, мы решили подойти к вопросу более обстоятельно. Немного подумав, мы придумали нечто.

Написанное ниже — это бета-версия процесса, которую мы ещё только испытываем и осмысливаем. Поэтому было бы очень здорово услышать мнения читателей в комментариях.

1. Local feed. На самом деле это просто сетевая папка (в Visual Studio при настройке источников можно указать не только адрес сервера, но и UNC путь к папке). В эту ленту пакеты собираются на каждый commit в VCS. Никто кроме разработчиков reusable кода source к этой ленте не настраивает.
2. Test feed. Эта роль вполне логично ложится на сервер SymbolSource, у которого есть своя лента (именно лента, не галерея) для пакетов, куда автоматически размещается обычный nuget-пакет при публикации symbol-пакета. Публикация в эту ленту выполняется, когда закончено внесение изменений в базовый код и можно приступать к его использованию. Source к этой ленте есть у всех разработчиков компании и у build-машин, собирающих тестовые версии конечных продуктов.
3. Сервер release-пакетов. Этим сервером стал тот, который мы развернули ещё в начале статьи — красивый, с UI и прочими плюшками. Самая важная плюшка — требование ApiKey. Локальная лента его не требует, как и лента SymbolSource (точнее SymbolSource требует, но не верифицирует). И там они и не нужны. Здесь же всё серьезнее, поэтому имеет смысл сделать так, чтобы публиковать могли не все. А если кто-то смог, было бы понятно кто это. Публикация на этот сервер идет только тогда, когда базовый код протестирован и сам по себе, и в работе с конечными продуктами. Source на данный сервер настроен у всех разработчиков, build-машин, собирающих тестовые версии конечных продуктов, build-машин, собирающих release версии конечных продуктов.

С другой стороны, порядок того, как указаны сервера в настройках Package Sources у Visual Studio (Tools->Library Package Manager->Package Manager Settings) задает приоритет загрузки пакетов. Поэтому, например, developer-ы базового кода имеют доступ ко всем трем лентам и порядок в настройках выставлен как release feed, test feed, local feed.

В Visual Studio это выглядит это примерно вот так:

Кстати, именно тут достаточно весомым становится аргумент в пользу локального развёртывания серверов — независимость от доступа в internet и бОльшая скорость при работе в локальной сети.

“А что, если один из серверов упал?” — спросите вы. Ну, так не беда. Ведь build process “фреймворка” один на все ленты. То есть, если пакет версии 1.2.3.4 объявляется релизным, то он лежит во всех трех лентах. И доступ к нему, например, у разработчика будет всегда.

С одной стороны, такой процесс не очень прост, но с другой стороны он получился очень естественным, поэтому о его сложности задумываться придётся не часто — он просто ложится на стандартный поток работ.

Ну что же, продумали. Теперь можно вернуться к технологиям и подумать про Continuous Integration, который автоматизирует весь этот процесс.

Но статья уже затянулась.

Поэтому, будем прощаться и оставим немного материала для второй части. И тут мы хотели бы обратиться с просьбой к нашим читателям. Если тема показалась вам интересной — дайте нам это понять, оставляйте комментарии. Они помогут нам сделать вторую часть более полезной и информативной, а также мотивируют на скорейший её выпуск.

Спасибо за ваше внимание.

UPD: как оно обычно и бывает, ровно на следующий день после того, как статья была дописана, вышло обновление пакета SymbolSource.Server.Basic (версия 1.3.3), в которой исправили баг, упомянутый в разделе про развертывание symbol-сервера.

• Блог компании True Engineering
• .NET
• Visual Studio