Name: plan-funkyOrmRefactor
Author: FuncularLabs

Prompt file imported from FuncularLabs/Funcular.FunkyOrm (.github/prompts/plan-funkyOrmRefactor.prompt.md). Copyright stays with the author.

Plan: Refactor & Polish FunkyOrm for v3.0 Release

I have analyzed the framework and identified several architectural inconsistencies, configuration errors, and code quality issues. This plan outlines the steps to resolve them, ensuring a stable and cleaner v3.0 release.

Steps

Fix Project Configuration [COMPLETED]: Corrected the invalid net10.0 target in Funcular.Data.Orm.SqlServer.Tests.DotNet10 to net9.0 and removed the erroneous <Compile Remove="Visitors\Visitors\**" /> from the main csproj.
Establish Core Abstractions [COMPLETED]: Moved ISqlDataProvider and generic interfaces from the SqlServer project to Funcular.Data.Orm.Core.
Clean Up Extensions [COMPLETED]: Decomposed ExtensionMethods.cs. Moved generic utilities (AddRange, Contains, ToDictionaryKey, etc.) to Funcular.Data.Orm.Core and kept SQL-specific extensions in the SqlServer project.
Resolve Technical Debt: Address the TODO in ISqlDataProvider regarding returning the primary key on insert, ensuring the API is complete for v3.0.
Refactor God Class (Time Permitting): Extract connection management logic from SqlServerOrmDataProvider (2000+ lines) into a dedicated SqlConnectionManager to improve testability and SRP.
Fully enable multi-provider support: Your refactoring plan must also include:

Changing ISqlDataProvider to use IDbConnection or DbConnection instead of SqlConnection.
Removing the Microsoft.Data.SqlClient package reference from the Core project.
If Step 5 covers extracting the SQL logic, you are on the right track. The next logical step would be to make the Core interface generic.

Further Considerations

Breaking Changes: Moving ISqlDataProvider to a new assembly is a breaking change. Is this acceptable for v3.0? (Assumed Yes for a major version).
Naming: The solution is FunkyOrm but namespaces are Funcular.Data.Orm. Do you want to unify this now? (Recommendation: Keep namespaces stable to minimize upgrade pain, unless rebranding).
Testing: The DotNet10 project seems to be a placeholder. Should we retarget it to .NET 9 or remove it? (Recommendation: Retarget to .NET 9).

## Plan: Refactor & Polish FunkyOrm for v3.0 Release I have analyzed the framework and identified several architectural inconsistencies, configuration errors, and code quality issues. This plan outlines the steps to resolve them, ensuring a stable and cleaner v3.0 release. ### Steps 1. **Fix Project Configuration** [COMPLETED]: Corrected the invalid `net10.0` target in `Funcular.Data.Orm.SqlServer.Tests.DotNet10` to `net9.0` and removed the erroneous `<Compile Remove="Visitors\Visitors\**" />` from the main csproj. 2. **Establish Core Abstractions** [COMPLETED]: Moved `ISqlDataProvider` and generic interfaces from the SqlServer project to `Funcular.Data.Orm.Core`. 3. **Clean Up Extensions** [COMPLETED]: Decomposed `ExtensionMethods.cs`. Moved generic utilities (`AddRange`, `Contains`, `ToDictionaryKey`, etc.) to `Funcular.Data.Orm.Core` and kept SQL-specific extensions in the SqlServer project. 4. **Resolve Technical Debt**: Address the `TODO` in `ISqlDataProvider` regarding returning the primary key on insert, ensuring the API is complete for v3.0. 5. **Refactor God Class (Time Permitting)**: Extract connection management logic from `SqlServerOrmDataProvider` (2000+ lines) into a dedicated `SqlConnectionManager` to improve testability and SRP. 6. **Fully enable multi-provider support**: Your refactoring plan must also include: - Changing ISqlDataProvider to use IDbConnection or DbConnection instead of SqlConnection. - Removing the Microsoft.Data.SqlClient package reference from the Core project. - If Step 5 covers extracting the SQL logic, you are on the right track. The next logical step would be to make the Core interface generic. ### Further Considerations 1. **Breaking Changes**: Moving `ISqlDataProvider` to a new assembly is a breaking change. Is this acceptable for v3.0? (Assumed Yes for a major version). 2. **Naming**: The solution is `FunkyOrm` but namespaces are `Funcular.Data.Orm`. Do you want to unify this now? (Recommendation: Keep namespaces stable to minimize upgrade pain, unless rebranding). 3. **Testing**: The `DotNet10` project seems to be a placeholder. Should we retarget it to .NET 9 or remove it? (Recommendation: Retarget to .NET 9).

{ "prompt": "## Plan: Refactor & Polish FunkyOrm for v3.0 Release\n\nI have analyzed the framework and identified several architectural inconsistencies, configuration errors, and code quality issues. This plan outlines the steps to resolve them, ensuring a stable and cleaner v3.0 release.\n\n### Steps\n1. **Fix Project Configuration** [COMPLETED]: Corrected the invalid `net10.0` target in `Funcular.Data.Orm.SqlServer.Tests.DotNet10` to `net9.0` and removed the erroneous `<Compile Remove=\"Visitors\\Visitors\\**\" />` from the main csproj.\n2. **Establish Core Abstractions** [COMPLETED]: Moved `ISqlDataProvider` and generic interfaces from the SqlServer project to `Funcular.Data.Orm.Core`.\n3. **Clean Up Extensions** [COMPLETED]: Decomposed `ExtensionMethods.cs`. Moved generic utilities (`AddRange`, `Contains`, `ToDictionaryKey`, etc.) to `Funcular.Data.Orm.Core` and kept SQL-specific extensions in the SqlServer project.\n4. **Resolve Technical Debt**: Address the `TODO` in `ISqlDataProvider` regarding returning the primary key on insert, ensuring the API is complete for v3.0.\n5. **Refactor God Class (Time Permitting)**: Extract connection management logic from `SqlServerOrmDataProvider` (2000+ lines) into a dedicated `SqlConnectionManager` to improve testability and SRP.\n6. **Fully enable multi-provider support**: Your refactoring plan must also include:\n- Changing ISqlDataProvider to use IDbConnection or DbConnection instead of SqlConnection.\n- Removing the Microsoft.Data.SqlClient package reference from the Core project.\n- If Step 5 covers extracting the SQL logic, you are on the right track. The next logical step would be to make the Core interface generic.\n\n### Further Considerations\n1. **Breaking Changes**: Moving `ISqlDataProvider` to a new assembly is a breaking change. Is this acceptable for v3.0? (Assumed Yes for a major version).\n2. **Naming**: The solution is `FunkyOrm` but namespaces are `Funcular.Data.Orm`. Do you want to unify this now? (Recommendation: Keep namespaces stable to minimize upgrade pain, unless rebranding).\n3. **Testing**: The `DotNet10` project seems to be a placeholder. Should we retarget it to .NET 9 or remove it? (Recommendation: Retarget to .NET 9).", "variables": [], "notes": "I have analyzed the framework and identified several architectural inconsistencies, configuration errors, and code quality issues. This plan outlines the steps to resolve them, ensuring a stable and cleaner v3.0 release.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/FuncularLabs/Funcular.FunkyOrm", "path": ".github/prompts/plan-funkyOrmRefactor.prompt.md", "ref": "fae4472a877016c8faa0b197c4d2178b22a0d952", "url": "https://github.com/FuncularLabs/Funcular.FunkyOrm/blob/fae4472a877016c8faa0b197c4d2178b22a0d952/.github/prompts/plan-funkyOrmRefactor.prompt.md", "key": "FuncularLabs/Funcular.FunkyOrm/.github/prompts/plan-funkyOrmRefactor.prompt.md" } } }

plan-funkyOrmRefactor

About

Plan: Refactor & Polish FunkyOrm for v3.0 Release

Steps

Further Considerations

Use it

Manifest

Reviews