DEV Community: Mohsen Mirshahreza

SequelizeDotNet

Mohsen Mirshahreza — Mon, 03 Aug 2026 12:45:11 +0000

SequelizeDotNet is simmilar to sequelize for node.js, It is based on schema and is Dabase first.

معرفی SequelizeDotNet: فلسفه‌ی Database-First سکوئلایز، این‌بار در دات‌نت

Mohsen Mirshahreza — Sat, 01 Aug 2026 12:53:24 +0000

یک ORM دیتابیس-محور و مبتنی بر DDL صریح برای دات‌نت — Typeهای emit‌شده در runtime، eager loading بدون JOIN، اعلان‌های push مبتنی بر CDC، و تولید GraphQL/OpenAPI مستقیماً از schema.

اگه با Sequelize.js در دنیای Node.js کار کرده باشید، این حس رو می‌شناسید: اشاره می‌کنید به یک دیتابیس، یک مدل تعریف (یا از روی دیتابیس موجود استخراج) می‌کنید، و در کمتر از چند دقیقه با Model.findAll({ where: {...}, include: [...] }) دارید کوئری می‌زنید. Associationها، hookهای lifecycle، read replica — همه هستن، و همه‌چیز به اندازه‌ی کافی به SQL نزدیک می‌مونه که هیچ‌وقت حس نکنید دارید با یک انتزاع مبارزه می‌کنید.

داستان اصلی ORM در دات‌نت فرق می‌کنه. Entity Framework Core کتابخانه‌ی فوق‌العاده‌ایه — ولی اساساً code-first کار می‌کنه: شما کلاس‌های DbContext/entity رو تعریف می‌کنید، و migrationها توضیح می‌دن دیتابیس چطور باید تغییر کنه تا با کد شما هماهنگ بشه. این مدل عالیه وقتی اپلیکیشن شما مالک schema است. ولی وقتی دیتابیس از قبل وجود داره، متعلق به یک تیم دیگه (یا حتی یک codebase دیگه، شاید به یک زبان کاملاً متفاوت) است، یا وقتی اصلاً نمی‌خواید کد اپلیکیشن تصمیم بگیره schema چه شکلی باشه، این مدل خیلی خوب جواب نمی‌ده.

دقیقاً همین خلأ دلیل ساختن SequelizeDotNet بود.

این کتابخانه واقعاً چیکار می‌کنه
SequelizeDotNet یک ORM با فلسفه‌ی database-first برای دات‌نته، روی شش دیتابیس رابطه‌ای — SQL Server، SQLite، PostgreSQL، MySQL/MariaDB، Oracle، و DB2 — که روی سه تصمیم طراحی غیرقابل‌مذاکره ساخته شده:

دیتابیس همیشه منبع حقیقته. هیچ‌چیزی از روی یک schema که خودتون نوشتید حدس نمی‌زنه کد شما «باید» چه شکلی باشه. مدل از دیتابیس میاد، نه برعکس.
DDL همیشه صریحه، هیچ‌وقت diff خودکار نیست. تغییرات ساختاری فقط از طریق متدهایی با نام واضح انجام می‌شن — RenameColumnAsync، AddColumnAsync، DropTableAsync — که دولوپر خودش عمداً صداشون می‌زنه. عملیات‌های مخرب نیاز به force: true دارن و در production قفلن مگر اینکه صریحاً override بشن. هیچ چیزی شبیه sync({ alter: true }) سکوئلایز («دیتابیس رو هرجور لازمه با مدلم هماهنگ کن») وجود نداره — چون دقیقاً همین دسته از فیچرهاست که sync خودکار رو در production خطرناک می‌کنه، و حتی مستندات خود سکوئلایز هم به همین دلیل ازش منع می‌کنه.
Typeهای Runtime، نه Code Generation. اینجا دات‌نت کاری می‌کنه که جاوااسکریپت نمی‌تونه: EntityTypeFactory با استفاده از System.Reflection.Emit یک CLR type واقعی به‌ازای هر جدول می‌سازه، که به‌صورت per-table کش می‌شه با تضمین lazy و thread-safe (دقیقاً یک‌بار emit می‌شه، حتی زیر بار concurrent). یک ستون رو در دیتابیس تغییر بدید، همون کوئری بعدی روی اون جدول یک type تازه emit‌شده که این تغییر رو منعکس می‌کنه تحویل می‌ده — بدون rebuild، بدون restart، بدون فایل .cs تولیدشده‌ای که باید sync نگهش دارید.
چند فیچر که خود سکوئلایز نداره
چون سیستم runtime و type دات‌نت اجازه‌ی ساختنشون رو می‌ده:

Include تودرتو و many-to-many، همیشه بدون JOIN. Include("Author.Publisher.Country") سه لایه‌ی foreign key رو به‌صورت سه کوئری جداگانه، کش‌شده، و فیلترشده با IN (...) طی می‌کنه. IncludeMany("Tags", "dbo", "PostTags", "FK_PostTags_Posts", "FK_PostTags_Tags") همین کار رو از طریق یک جدول واسط صریحاً نام‌گذاری‌شده انجام می‌ده. هیچ‌وقت چیزی پشت یک query plan مبهم و خودکار مخفی نمی‌شه.
مسیریابی Read/Write که واقعاً SQL خام رو هم می‌فهمه. پشتیبانی read replication خود سکوئلایز سابقه‌ی گزارش باگ‌های تکرارشونده داره که کوئری خام بی‌سروصدا از replica pool رد می‌شه. StatementIntentClassifier کلمه‌ی کلیدی ابتدایی کوئری خام رو بررسی می‌کنه دقیقاً برای اینکه همون مسیر میان‌بر هم درست مسیریابی بشه.
Hot-reload بدون restart برای schema. SchemaWatcher پول می‌کنه، مقایسه می‌کنه، و type runtime جدول تغییریافته رو به‌صورت atomic و نسخه‌دار جایگزین می‌کنه — بدون ری‌استارت کردن پروسه.
Change Data Capture سکوئل سرور به‌عنوان یک event قابل‌subscribe. اکثر ORMها هیچ پشتیبانی built-in برای CDC ندارن. CdcChangeWatcher جدول‌های change سکوئل سرور رو به یک event سی‌شارپ تبدیل می‌کنه که یک‌بار subscribe می‌کنید و تمام.
تولید GraphQL و OpenAPI مستقیماً از schema اینتروسپکت‌شده. بدون هیچ مرحله‌ی مدل‌سازی جدا — یک‌بار schema رو بخونید، و یک schema سبک GraphQL یا سند OpenAPI 3.0 مستقیماً از چیزی که دیتابیس از قبل می‌دونه بسازید.
الان دقیقاً کجا ایستاده — صادقانه
این یک پروژه‌ی جوونه (نسخه‌ی ۰.۱.۰) و می‌خوام دقیقاً بگم تا کجا واقعاً تست شده، نه فقط چی پیاده‌سازی شده:

SQL Server و SQLite به‌طور کامل و زنده تست شدن — بیش از ۱۴۰ تست بین این دو، که هر نوع داده، هر عملگر کوئری، تراکنش‌ها، hookها، schema drift، hot-reload، و bulk insert رو پوشش می‌ده، روی LocalDB واقعی و دیتابیس‌های موقت اجرا شده.
PostgreSQL، MySQL، Oracle، و DB2 کاملاً پیاده‌سازی شدن، پشت همون قرارداد IDialect، ولی فقط در سطح unit-test (query translator) تست شدن — من هنوز نمونه‌ی زنده‌ای از این‌ها ندارم که رفتار end-to-end رو روش تأیید کنم. اگه شما دارید، مشارکت‌تون فوق‌العاده خوش‌اومده — پورت کردن تست‌های زنده‌ی موجود SQL Server/SQLite به یکی از این دیتابیس‌ها با ارزش‌ترین کمکیه که الان می‌شه کرد.
مجموعاً ۲۲۳ تست خودکار، صفر شکست، در این نسخه.
اگه codebase شما از قبل مالک schema خودشه و LINQ چک‌شده در compile-time می‌خواید، احتمالاً EF Core همچنان انتخاب پیش‌فرض بهتریه — بالغ‌تره، توسط مایکروسافت پشتیبانی می‌شه، و اکوسیستم به‌مراتب بزرگ‌تری داره. SequelizeDotNet برای همون سناریوی خاصیه که دیتابیس منبع حقیقته و ترجیح می‌دید همون‌طوری کار کنید که سکوئلایز به یک نسل از دولوپرها یاد داد.

امتحانش کنید
dotnet add package SequelizeDotNet.Core
dotnet add package SequelizeDotNet.Providers.SqlServer
var engine = new QueryEngine(new SqlServerDialect(), new ModelRegistry());

var query = QueryEngine.Query("dbo", "Posts")
.Where("AuthorId", QueryOperator.Equal, 42)
.Include("FK_Posts_Authors");

var rows = await engine.ToListAsync(query, connection);
مستندات کامل: Developer Guide · سورس و issueها: github.com/mirshahreza/SequelizeDotNet · لایسنس: MIT.

تشکر فراوان از همه‌ی کسانی که تا امروز به Sequelize.js کمک کردن — این پروژه به این دلیل وجود داره که اون پروژه بیش از یک دهه ثابت کرد این سبک کار با دیتابیس، در هر زبانی، ارزش داشتنش رو داره.

اگه تا حالا از یک ابزار migration که اشتباه حدس زده ضربه خوردید، یا دارید یک سرویس دات‌نتی رو نگه‌داری می‌کنید که دیتابیسش مال یک تیم دیگه‌ست، خوشحال می‌شم بازخوردتون رو بشنوم — و اگه یک نمونه‌ی PostgreSQL، MySQL، Oracle یا DB2 دارید که بشه یک test suite رو روش امتحان کرد، حتی بیشتر خوشحال می‌شم.

SequelizeDotNet · لایسنس MIT · github.com/mirshahreza/SequelizeDotNet

Introducing SequelizeDotNet: Bringing Sequelize.js's Database-First Philosophy to .NET

Mohsen Mirshahreza — Fri, 31 Jul 2026 06:13:47 +0000

A database-first, explicit-DDL ORM for .NET — runtime-emitted entity types, JOIN-free eager loading, CDC push notifications, and schema-driven GraphQL/OpenAPI generation.

If you've built anything with Sequelize.js in the Node.js world, you know the feeling: point it at a database, define (or reverse-engineer) a model, and you're querying with Model.findAll({ where: {...}, include: [...] }) within minutes. Associations, lifecycle hooks, read replicas — it's all there, and it stays close enough to SQL that you never feel like you're fighting an abstraction.

.NET's dominant ORM story is different. Entity Framework Core is excellent — but it's fundamentally code-first: you declare DbContext/entity classes, and migrations describe how the database should change to match your code. That's a great model when your application owns the schema. It's a much worse fit when the database already exists, is owned by another team (or another codebase, possibly in another language entirely), or when you simply don't want application code deciding what the schema should look like.

That gap is why I built SequelizeDotNet.

What it actually does
SequelizeDotNet is a database-first ORM for .NET across six relational databases — SQL Server, SQLite, PostgreSQL, MySQL/MariaDB, Oracle, and DB2 — built on three non-negotiable design decisions:

The database is the source of truth, always. Nothing infers what your code "should" look like from a schema you wrote. The model comes from the database.
Explicit DDL, never automatic diffing. Structural changes happen through clearly-named method calls — RenameColumnAsync, AddColumnAsync, DropTableAsync — that a developer invokes deliberately. Destructive operations require force: true and are locked in production unless explicitly overridden. There's no sync({ alter: true })-style "make the database match my model, however that requires" — because that's exactly the class of feature that makes automatic schema sync dangerous in production, and Sequelize's own docs discourage it for good reason.
Runtime types, not code generation. Here's where .NET gets to do something JavaScript can't: EntityTypeFactory emits a real CLR type per table via System.Reflection.Emit, cached per-table with a lazy, thread-safe, single-emission guarantee. Change a column in the database, and the next query against that table gets a freshly emitted type reflecting it — no rebuild, no restart, no generated .cs file to keep in sync.
A few things I got to build that Sequelize itself doesn't have
Because .NET's runtime and type system make them possible:

Nested and many-to-many eager loading, always JOIN-free. Include("Author.Publisher.Country") walks three foreign-key hops as three separate, cached, IN (...)-filtered queries. IncludeMany("Tags", "dbo", "PostTags", "FK_PostTags_Posts", "FK_PostTags_Tags") does the same through an explicitly-named junction table. Nothing is ever hidden behind an opaque generated JOIN plan.
Read/write routing that actually understands raw SQL. Sequelize's read replication support has had recurring reports of raw queries silently bypassing the replica pool. StatementIntentClassifier inspects a raw query's leading keyword specifically so that escape hatch stays correctly routed too.
Zero-restart schema hot-reload. SchemaWatcher polls, diffs, and swaps the runtime entity type for a changed table — atomically, versioned — without restarting the process.
SQL Server Change Data Capture as a subscribable event. Most ORMs have zero built-in CDC consumption. CdcChangeWatcher turns SQL Server's CDC change tables into a C# event you subscribe to once.
GraphQL and OpenAPI generation straight from the introspected schema. No separate modeling step — introspect once, generate a GraphQL SDL schema or an OpenAPI 3.0 document from what the database already knows.
Where it stands today — honestly
This is a young project (v0.1.0) and I want to be upfront about exactly how far it's been verified, not just what's implemented:

SQL Server and SQLite are exhaustively live-tested — 140+ tests between them, covering every data type, every query operator, transactions, hooks, schema drift, hot-reload, and bulk insert, run against real LocalDB and temp-file databases.
PostgreSQL, MySQL, Oracle, and DB2 are fully implemented behind the exact same IDialect contract, but only unit-tested at the query-translator level — I don't have live instances of these to verify end-to-end behavior against yet. If you do, contributions are very welcome — porting the existing SQL Server/SQLite live test suites to one of these engines is the single most valuable thing anyone could contribute right now.
223 automated tests total, 0 failures, as of this release.
If your codebase already owns its schema and you want compile-time-checked LINQ, EF Core is very likely still the better default choice today — it's mature, Microsoft-backed, and has a much larger ecosystem. SequelizeDotNet is for the specific case where the database is the source of truth and you'd rather work the way Sequelize taught a generation of developers to work.

Try it
dotnet add package SequelizeDotNet.Core
dotnet add package SequelizeDotNet.Providers.SqlServer
var engine = new QueryEngine(new SqlServerDialect(), new ModelRegistry());

var query = QueryEngine.Query("dbo", "Posts")
.Where("AuthorId", QueryOperator.Equal, 42)
.Include("FK_Posts_Authors");

var rows = await engine.ToListAsync(query, connection);
Full docs: Developer Guide · Source & issues: github.com/mirshahreza/SequelizeDotNet · License: MIT.

Huge thanks to everyone who's ever contributed to Sequelize.js — this project exists because that one spent over a decade proving this way of working with databases is worth having, in any language.

If you've been burned by a migration tool guessing wrong, or you're maintaining a .NET service against a database another team owns, I'd love your feedback — and if you have a PostgreSQL, MySQL, Oracle, or DB2 instance you can point a test suite at, I'd love that even more.

SequelizeDotNet · MIT License · github.com/mirshahreza/SequelizeDotNet

Dynamic React: Rendering Remote JSX without a Build Step

Mohsen Mirshahreza — Tue, 18 Nov 2025 22:03:51 +0000

Dynamic React: Rendering Remote JSX without a Build Step

Introduction

Modern React development is often synonymous with complex build pipelines involving Webpack, Vite, or Rollup. While these tools offer optimization, they introduce a significant barrier to entry and rigidity. This project, ReactDynaCodeDynaHtml, demonstrates a powerful alternative: loading, compiling, and rendering React components dynamically in the browser at runtime.

Core Techniques

1. In-Browser Compilation with Babel Standalone

Instead of pre-compiling JSX, this project utilizes babel.min.js (Babel Standalone). This library runs entirely in the browser, transforming JSX syntax into standard JavaScript that the browser can execute on the fly.

2. Dynamic Fetching

The application uses the standard fetch API to retrieve component code (stored in .html or .js files) as plain text strings. This allows components to be stored remotely or locally and loaded only when needed.

3. Scoped Execution via `new Function`

The heart of the system is the DynamicContent loader. Once the code is fetched and transformed by Babel, it is executed using the new Function constructor.

const func = new Function('React', ...contextKeys, funcBody);

This technique allows us to:

Inject dependencies (like React) explicitly.
Pass props and context variables dynamically.
Isolate the component's scope to prevent global namespace pollution.

Advantages

Zero Build Configuration: No npm run build, no node_modules hell, and no complex config files.
Hot-Swappable Architecture: You can update a component file on the server, and clients will see the change immediately upon refresh without redeploying the entire application.
Runtime Flexibility: Ideal for CMS-like structures where layout or logic needs to be defined by the backend or changed frequently.
Rapid Prototyping: Excellent for quick experiments or adding React to legacy applications without a full rewrite.

How to Use

Setup: Ensure index.html includes React, ReactDOM, and Babel Standalone.
The Loader: Use the DynamicContent component to load external files.

   <DynamicContent url="./my-component.js" context={{ user: 'Alice' }} />

Component Files: Write standard React functional components in your external files. They should return the JSX element directly.

Conclusion

While not a replacement for build steps in massive, performance-critical applications, this "No-Build" approach offers unmatched flexibility for dynamic content, plugin systems, and lightweight integrations.

Source Code
You can find the complete source code for this project on GitHub: https://github.com/mirshahreza/ReactDynaCodeDynaHtml

Geographic in Zync: PostGIS-Inspired Spatial Utilities for SQL Server

Mohsen Mirshahreza — Wed, 29 Oct 2025 04:42:01 +0000

Geographic in Zync: PostGIS-Inspired Spatial Utilities for SQL Server

Zync is a lightweight, Git-powered package manager for SQL Server that turns collections of SQL scripts into installable, dependency-aware packages. It helps teams ship consistent, reusable database utilities with simple, discoverable commands.

This article focuses on the Geographic package and how it intentionally mirrors PostGIS patterns from PostgreSQL—so spatial developers can feel at home while working on Microsoft SQL Server.

GitHub: https://github.com/mirshahreza/Zync
Geographic package folder: MsSql/Packages/Geographic

Why PostGIS patterns?

PostGIS is the de facto standard for spatial data processing in PostgreSQL. Its thoughtful API design, consistent naming (ST_*), and rich function set have shaped how many engineers think about geospatial work.

The Zync Geographic package adopts the same mental model and naming conventions so that:

Function names and semantics are familiar to PostGIS users.
Common tasks (constructing geometry, spatial relationships, buffering, distance queries) look and feel similar.
Migration between PostgreSQL/PostGIS and SQL Server is easier for mixed environments.

Under the hood, these functions are implemented using SQL Server's native spatial types (geometry and geography) and T‑SQL, and they expose a PostGIS-like surface area where possible.

Design highlights

ST_* naming: All spatial helpers follow the ST_* convention with a protective Zz prefix, e.g., ZzST_Buffer, ZzST_Contains, ZzST_DWithin.
Geometry-first: Core ST_* functions operate on SQL Server geometry; where geodetic accuracy is needed, separate helpers use latitude/longitude and the Haversine formula.
WKT/WKB friendly: Constructors and I/O helpers accept and return WKT/WKB, easing copy/paste and testing.
SRID defaults: SRID 4326 (WGS 84) is the default when an SRID is not explicitly provided.
Familiar semantics: Names and behavior are intentionally aligned with the PostGIS reference where supported by SQL Server's spatial stack.

See the quick reference: MsSql/Doc/POSTGIS_FUNCTIONALITIES.md

What’s included

Beyond utility routines like coordinate validation and distance conversions, the package ships 45+ PostGIS‑style functions (ZzST_*) including:

Geometry constructors: ZzST_Point, ZzST_MakePoint, ZzST_MakeLine, ZzST_MakePolygon, ZzST_MakeEnvelope
I/O helpers: ZzST_AsText, ZzST_AsBinary, ZzST_GeomFromText, ZzST_GeomFromWKB
Accessors: ZzST_X, ZzST_Y, ZzST_GeometryType, ZzST_SRID
Measurements and predicates: ZzST_Distance, ZzST_Length, ZzST_Area, ZzST_Perimeter, ZzST_Contains, ZzST_Within, ZzST_Intersects, ZzST_DWithin
Processing: ZzST_Buffer, ZzST_Centroid, ZzST_Envelope, ZzST_ConvexHull, ZzST_PointOnSurface
Set operations: ZzST_Union, ZzST_Intersection, ZzST_Difference, ZzST_SymDifference

You’ll also find pragmatic helpers commonly needed in app backends:

ZzIsPointInRadius, ZzGetPointsInRadius, ZzGetBoundingBox, ZzGetNearestPoint
Converters and formatters: ZzConvertDMSToDecimal, ZzConvertDecimalToDMS, ZzConvertDistance/Area/Speed

Browse the full list and examples in MsSql/Packages/Geographic/README.md

Usage examples

Note: geometry is used below; replace with geography where your use case requires spheroid-aware measurements. Default SRID is 4326 unless specified.

1) Construct points and lines (PostGIS‑like):

-- POINT(lon lat)
SELECT [dbo].[ZzST_AsText](
  [dbo].[ZzST_MakePoint](51.3890, 35.6892, NULL, NULL)
) AS WKT;

-- LINESTRING from two points
SELECT [dbo].[ZzST_AsText](
  [dbo].[ZzST_MakeLine]('51.3890,35.6892;51.4000,35.7000', 4326)
) AS WKT;

2) Spatial relationships and predicates:

-- Envelope (bbox) that contains a point
DECLARE @bbox geometry = [dbo].[ZzST_MakeEnvelope](51.3800, 35.6800, 51.4200, 35.7200, 4326);
DECLARE @pt   geometry = [dbo].[ZzST_GeomFromText]('POINT(51.3890 35.6892)', 4326);
SELECT [dbo].[ZzST_Contains](@bbox, @pt) AS ContainsPoint; -- 1 = true, 0 = false

3) Distance and proximity:

-- Are two points within 1km?
DECLARE @a geometry = [dbo].[ZzST_GeomFromText]('POINT(51.3890 35.6892)', 4326);
DECLARE @b geometry = [dbo].[ZzST_GeomFromText]('POINT(51.4000 35.7000)', 4326);
SELECT [dbo].[ZzST_DWithin](@a, @b, 1000.0) AS IsNearby;

4) Buffering:

-- Create a small buffer around a point (~units depend on SRID)
DECLARE @pt geometry = [dbo].[ZzST_GeomFromText]('POINT(51.3890 35.6892)', 4326);
SELECT [dbo].[ZzST_AsText]([dbo].[ZzST_Buffer](@pt, 0.01)) AS Buffered;

5) “App friendly” helpers with lat/lon inputs:

-- Check if a point (lat/lon) is within a radius (KM/MILE/M)
SELECT [dbo].[ZzIsPointInRadius](35.6892, 51.3890, 35.7000, 51.4000, 10, 'KM') AS InRadius;

-- Find points within a radius around a center point (example table schema assumed)
-- SELECT * FROM [dbo].[ZzGetPointsInRadius](
--   @centerLat, @centerLon, @radiusValue, @radiusUnit, @YourPointsTable
-- );

Mapping for PostGIS users

ST_* naming is preserved with a Zz prefix: e.g., PostGIS ST_Buffer ≈ ZzST_Buffer.
WKT/WKB inputs are supported via ZzST_GeomFromText and ZzST_GeomFromWKB.
SRID management via ZzST_SRID and ZzST_SetSRID (no transform).
SQL Server equivalents (internal) may differ in name (e.g., STBuffer, STDistance), but the wrapper functions provide PostGIS‑like ergonomics.

Quick mapping table

PostGIS	Zync Geographic	Notes/Differences
ST_Buffer	ZzST_Buffer	Buffers on geometry; units depend on the SRID.
ST_DWithin	ZzST_DWithin	Proximity within a distance (units = coordinate system units). Consider geography for geodetic accuracy over long distances.
ST_Intersects	ZzST_Intersects	Returns 0/1; works across geometry types.
ST_Contains	ZzST_Contains	Tests if A completely contains B.
ST_Within	ZzST_Within	Tests if A is within B.
ST_Distance	ZzST_Distance	Minimum 2D distance; for lat/lon geodetic cases use ZzCalculateDistance (Haversine).
ST_AsText	ZzST_AsText	WKT output for viewing/debugging.
ST_GeomFromText	ZzST_GeomFromText	Construct geometry from WKT with SRID.

Caveats and tips:

Be explicit about SRIDs when mixing data from multiple sources.
Geography vs geometry: choose geography for long‑distance geodetic calculations; use geometry for planar operations and most predicates.
Tolerance and units: buffer radii and distances depend on the coordinate system—prefer consistent SRIDs (WGS 84 for GPS).

Installation

Install directly from the Zync repository using the Zync command:

-- Install the entire Geographic package
EXEC [dbo].[Zync] 'i Geographic';

-- Or install only spatial functions
EXEC [dbo].[Zync] 'i Geographic/ZzST_*.sql';

If you don't have Zync yet, run MsSql/Zync.sql from the repository to bootstrap the core procedure. See MsSql/Doc/ARTICLE_EN.md for a gentle introduction and MsSql/scripts/README.md for automation.

References

Zync repository: https://github.com/mirshahreza/Zync
PostGIS docs: https://postgis.net/docs/
SQL Server spatial types: geometry and geography

If you’ve been productive with PostGIS, you’ll feel right at home: the Zync Geographic package brings a familiar, modern spatial toolbox to SQL Server—tested, documented, and ready for production.

Stop Juggling SQL Scripts: Introducing Zync, the Database Package Manager

Mohsen Mirshahreza — Fri, 26 Sep 2025 21:24:36 +0000

If you’ve ever worked on a large database project, you know the pain. You have folders filled with SQL scripts for stored procedures, functions, and views. Script A depends on B, which depends on C. Deploying to a new environment means running them in the correct order, and heaven forbid you miss one. Sharing reusable utilities across projects is a copy-paste nightmare.

We’ve built powerful package managers for our application code—npm for Node.js, NuGet for .NET, Pip for Python. They handle dependencies, versioning, and distribution flawlessly. So why are we still managing database scripts like it’s 1999?

It’s time for a change. Introducing Zync, a simple but powerful package manager for SQL Server, designed to bring the convenience of modern package management directly into your database.

The Chaos of Manual Script Management

Before we dive into the solution, let’s appreciate the problem. Traditionally, managing a collection of database objects involves:

Manual Dependency Tracking: You have to remember that CreateUserView.sql must run after CreateUserTable.sql. This knowledge is often stored in a developer's head or a fragile README file.
Scattered Scripts: Utility functions and procedures are often scattered across different project folders, leading to code duplication and maintenance headaches.
Inconsistent Deployment: Deploying to a new database is often a manual, error-prone process that can easily lead to inconsistencies between development, staging, and production environments.
Difficult Collaboration: Sharing a set of useful database tools with your team or the community is far from straightforward.

Zync was born out of this frustration. It treats your database objects as what they are: packages—modular, reusable, and dependency-aware units of code.

How Zync Simplifies Your Workflow

Zync is built around a single stored procedure, dbo.Zync, that acts as your command-line interface inside SQL Server Management Studio (SSMS). Once installed, it gives you access to a world of functionality through simple commands.

The core philosophy is simple: host your SQL packages in a GitHub repository, and let Zync handle the rest.

Key Concepts:

📦 Package Management: Group related SQL objects (procedures, functions, etc.) into a "package," which is simply a folder in a repository.
🔄 Automatic Dependency Resolution: Define dependencies for a package, and Zync will automatically fetch and install them first.
🎯 Simple Commands: A clean, intuitive command structure for listing and installing packages.
🏗️ Standardized Repositories: Use the official Zync repository or point it to your own for private packages.

Getting Started with Zync

Ready to give it a try? It only takes a few minutes to get up and running.

Step 1: Install the Zync Stored Procedure

First, you need to install the core Zync procedure in your target database. Just download and run the Zync.sql script from the official repository. This one-time setup is all you need.

Step 2: List Available Packages

Once installed, you can see which packages are available in the default repository with the ls (list) command.

EXEC [dbo].[Zync] 'ls'

This command queries the GitHub API and returns a list of available packages (directories) you can install.

Expected Output:

Fetching available packages from repository...
Available packages:
-------------------
AppEnd
DbUtils
Number
String
-------------------

Step 3: Install Your First Package

Let's say you need a set of string manipulation utilities. You can install the String package with the i (install) command.

EXEC [dbo].[Zync] 'i String'

Here’s what happens behind the scenes:

Zync constructs the URL to the package's main SQL file in the repository.
It fetches the content of the script.
It checks for any dependencies listed at the top of the file and installs them first.
Finally, it executes the script, creating all the objects from the String package in your database.

Output:

Installing package: 'String'...
 -> Fetched 'String' successfully.
 -> Package 'String' installed successfully.

Just like that, you now have access to useful functions like ZzSplitString and ZzCountWord without ever leaving your query editor.

You can also install a single script from a package if you don't need the entire collection:

-- Installs only the ZzSplitString function
EXEC [dbo].[Zync] 'i String/ZzSplitString.sql'

A Glimpse into the Zync Ecosystem

The default repository already includes several useful packages to get you started:

DbUtils: A powerful suite of tools for database administration, including procedures to create/drop tables, manage columns, and analyze object dependencies.
String: A collection of functions for common string operations like splitting, trimming, and counting.
Number: Helper functions for formatting numbers and converting byte sizes (e.g., to KB, MB, GB).
AppEnd: A set of building blocks for applications, including user and role management.

The Future is Bright

Zync is just getting started. The vision is to create a rich ecosystem of reusable database components. The roadmap includes:

Support for other databases like PostgreSQL, MySQL, and Oracle.
Package versioning to manage different versions of a package.
An uninstall command to safely remove packages.

Join the Movement

Managing database code shouldn't be a chore. Zync offers a streamlined, modern approach that saves time and reduces errors. It empowers developers to build, share, and reuse database utilities with ease.

Check out the project on GitHub, give it a star, and try it out in your own projects. Contributions, feedback, and ideas are always welcome.

Find the project here: https://github.com/mirshahreza/Zync

Mohsen Mirshahreza

DEV Community: Mohsen Mirshahreza

SequelizeDotNet

معرفی SequelizeDotNet: فلسفه‌ی Database-First سکوئلایز، این‌بار در دات‌نت

Introducing SequelizeDotNet: Bringing Sequelize.js's Database-First Philosophy to .NET

Dynamic React: Rendering Remote JSX without a Build Step

Dynamic React: Rendering Remote JSX without a Build Step

Introduction

Core Techniques

1. In-Browser Compilation with Babel Standalone

2. Dynamic Fetching

3. Scoped Execution via new Function

Advantages

How to Use

Conclusion

Geographic in Zync: PostGIS-Inspired Spatial Utilities for SQL Server

Geographic in Zync: PostGIS-Inspired Spatial Utilities for SQL Server

Why PostGIS patterns?

Design highlights

What’s included

Usage examples

Mapping for PostGIS users

Quick mapping table

Installation

References

Stop Juggling SQL Scripts: Introducing Zync, the Database Package Manager

The Chaos of Manual Script Management

How Zync Simplifies Your Workflow

Key Concepts:

Getting Started with Zync

Step 1: Install the Zync Stored Procedure

Step 2: List Available Packages

Step 3: Install Your First Package

A Glimpse into the Zync Ecosystem

The Future is Bright

Join the Movement

3. Scoped Execution via `new Function`