Replies: 7 comments 10 replies
-
|
My thoughts regarding some specific points: 2 primary approaches
Supported concepts
Based on my experiences with Oqtane and custom external modules so far I would mention to take care not to drop supporting the usage of custom (logical) Database Schema. In the EF Core OnModelCreating method of the external module context it's usage is as simple as setting the HasDefaultSchema property (e.g. → To be clear my mentions regarding supporting the usage of custom Schemas only concern the tables (and other database objects) of custom external modules. Oqtane should adopt the Migrations approach
From the point of view of a custom external module developer I don't see an advantage on programmatically execution against executing Migrations manually. As developers we need some background knowledge and EF Core makes it not to complicated using Migrations. And not to forget, that the contrary way Reverse Engineering (Scaffolding) is also a real usage scenario when developing custom external modules. I have applied this here with no problems. Oqtane is an application framework and not a ready to use CMS. So the aduience creating solutions with it are developers. That saying I don't see an advantage on hiding Migrations behind an UI. Bear with me if I have misunderstood something in this context. |
Beta Was this translation helpful? Give feedback.
-
So no Cosmos DB with EF? |
Beta Was this translation helpful? Give feedback.
-
|
There are some Cosmos DB limitations like a lack of support for Include. |
Beta Was this translation helpful? Give feedback.
-
|
@mikecasas Oqtane uses a relational database model. Its core architecture has well defined schemas and relationships which have significance and meaning within the application. CosmosDB is a NoSQL non-relational database which is not a good fit. |
Beta Was this translation helpful? Give feedback.
-
|
@nicpitsch I agree that the concept of a "schema" should be supported. In fact the initial POC of Oqtane had a "Schema" property in its Tenant table for exactly this purpose, but it was removed prior to 1.0 because it was never fully implemented. I indicated that Migrations must be automated because this is how the framework operates today. When you install a new version of Oqtane or you install a custom module, the framework automatically executes the SQL scripts so that the application is fully functional without requiring any technical knowledge or manual effort. We absolutely need to retain this feature when we transition to using Migrations. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @sbwalker for starting this while there are many requests to support multiple database my though is to go with a Generic approach as I ready did a library that target multiple databases, I'd like to share some of my experience on this one: EF Core or Not EF Core This HUGE while Oqtane is already used EF as ORM, so using EF may be the easier target but we should think about :
if we want to improve the PERF, using raw SQL is a better approach of course. Both ways have Pros & Cons, so if we vote to continue with EF I'm suggesting:
Thanks |
Beta Was this translation helpful? Give feedback.
-
|
@hishamco the Oqtane Philosophy includes Microsoft Alignment - which essentially says we should use the standard Microsoft methodology unless there is an overwhelming reason not to. This is why I am recommending that we continue to use EF Core. In regards to executing migrations programmatically at runtime, this is already supported by EF Core and there are plenty of examples available. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good |
Beta Was this translation helpful? Give feedback.
-
|
I would like to get support for most common db engine as MySQL or MariaDB, no question, this are very popular and used in 85% of web project globally. For a provider i would user Pomelo as this has also a migration capabilities and it is simple to use. however there is many implementations for MySQL like systems. For a smaller project is also good to use SQLite, but personally i think, if you already have a db engine installed, it is not worth to use it. Thank you |
Beta Was this translation helpful? Give feedback.
-
|
@michalss I agree that MySQL/MariaDB should be supported |
Beta Was this translation helpful? Give feedback.
-
|
Further research on the Migration topic led me to this documentation from Microsoft: https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/applying?tabs=dotnet-core-cli You will note that it starts by saying "the recommended way to deploy migrations to a production database is by generating SQL scripts". So basically the guidance from Microsoft is to use programmatic migrations during development but use SQL scripts in production. Obviously development and production are very different scenarios; however, this guidance creates some major complications for application developers - especially in situations where you want to support multiple databases, as each database uses different syntax for SQL scripts. One of the primary benefits of using EF Core migrations is that it abstracts the syntactical differences of each database and allows a developer to work against a single consistent API. EF Core includes support for generating SQL scripts from migration logic - however the commands are designed to execute once against a single context instance with a single connection. So basically it can not be used in a more complex application which supports different databases. The following thread covers this topic and the EF Core PM states that EF Core does not plan to support this scenario - and he actually recommends using run-time migrations ( which conflicts with the guidance in the official EF Core documentation above ). So basically if you are creating simple applications that support a single database then the EF Core tooling supports your scenario and you can follow the official guidance. However, if you are creating a complex application that supports multiple databases, you need to deviate from the official guidance. Oqtane already supports run-time deployment - in the install wizard when you initially install the product, during upgrade when you deploy a new version over an existing version, and during module installation. It does this to simplify and streamline the deployment process. We need to retain this capability as we transition from SQL scripts to EF Core migrations. And based on the information above, we will need to use the run-time migration approach (ie. db.Database.Migrate()). Hopefully this clarifies your question @nicpitsch |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @sbwalker for the clarifications. To be honest having only a superficial knowledge about the functionality of Octane I don't understand all the implications regarding multi tenancy and multi database systems support. At the time I'm using Oqtane as development framework for a line of business application and the experience is very positive. The custom external module ist made using the monolyhic strategy. For me it is important having the possibility using ASP.NET Core and EF Core functionality directly and that only few things are hidden behind an Oqtane abstraction layer (like routing). What is also a good experience that the Oqtane solution is a rich source on regarding how to organize my module. Thank you to everyone who is helping make Oqtane such a useful application framwork for Blazor! |
Beta Was this translation helpful? Give feedback.
-
|
Is there any eta please ? I cannot wait :) |
Beta Was this translation helpful? Give feedback.
-
|
@pcancela submitted a Proof of Concept for adding MySql support. It is not generic but has some good features. @sbwalker has asked me to look at the Proof of Concept and take it over the line. The goal is for it to be included in version 2.1, and I am hoping we can at least have a release candidate by mid-April. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Shaun, just watched your .net conf 2020 on YouTube and am very excited about it. I am close to starting a blazor app that will be a rewrite of a windows desktop app that’s somewhat successful. I use firebird database via ado.net and raw sql. It sounds like oktane is configurable so that I can continue to use firebird. Just wanted to put my 2 cents in about firebird and what an amazingly product oqtane is! |
Beta Was this translation helpful? Give feedback.
-
I think that Multiple databases in the framework will be very useful, however we should limit the scope to enabling the Oqtane repository to sit on multiple databases, which can be easily done by only supporting the databases supported by EF core. There are 2 scenarios. The needs of the module developer’s persistence requirements can vary greatly. Trying to support all options will get complex. My suggestion is as follows: In this case, Module developers rely can on the underlying framework by implementing the IInstallable interface and do the migrations as they see fit for their application. Scenario #2: I am only 2 days into Oqtane so do pardon me if I made mistakes or stated the obvious. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
@kpkrish module developers already have the freedom to use their preferred database / data access approach in their custom modules. This will continue to be true even after the Multiple Database Support feature has been added. The only nuance is that if they want to leverage the multi-tenant capabilities of the framework they will need to incorporate it into their own solutions - but it is not a requirement. The Multiple Database Support feature is trying to solve 2 main problems:
I hope this makes sense. |
Beta Was this translation helpful? Give feedback.
-
Based on the number of feature requests to date, Cross Platform Database Support has been identified as a major feature on the roadmap for the 2.1 release. The following is intended to provided high level context and initiate some community discussion and feedback on this topic...
The ability to support all major operating system platforms is essential in allowing a framework to serve the maximum number of developers. Microsoft has spent a lot of time and effort to transform .NET into a cross platform framework. That being said, .NET is capable of working with many types of databases. Some databases are cross platform and others only support a single operating system. In addition, databases on the same platform can also vary significantly in terms of feature set, scalability, and cost. Therefore it is beneficial for a framework to be able to support multiple databases.
Currently Oqtane only supports SQL Server (ie. LocalDB, SQL Server, SQL Azure). This limitation does not align with Oqtane's Philosophy of Flexibility and it also imposes some restrictions on developers who want to develop Oqtane on Linux or MacOS operating systems, or run Oqtane on cost optimized infrastructure. As a result, Oqtane needs to be enhanced to support additional databases.
There are 2 primary approaches for supporting multiple databases. The first option is to create an optimized solution for each specific database, taking advantage of any unique characteristics they may offer. The other option is to create a single generic solution that is capable of supporting multiple databases. There are many pros and cons to consider in regards to these options however the most important requirement in the case of a framework like Oqtane is how well a solution supports modularity. And since one of the central concepts in a modular framework is that module developers rely on the underlying framework to take care of their infrastructure needs, the generic option for supporting multiple database is the preferable approach.
It is important to note that when following the generic approach, there are still some limitations that must be accepted. For example, the list of databases which are supported in such an approach is finite - they will be limited to databases which conform to a specific operating model and have a suitable adapter available. In the case of Oqtane, the framework currently relies on a relational database model and will therefore only support relational database engines.
Microsoft developed EF Core to be able to support multiple databases through plug-in libraries called database Providers. This generic approach allows developers to work with a common API and delegate responsibility to a provider for interacting with specific databases. EF Core has providers for SQL Server, SQLite, PostgreSQL, MySQL, and many others. There are 2 distinct aspects of EF Core, the first being the operational ORM support for interacting with a database, and the second being the ability to define or modify a database schema using a feature called Migrations.
Currently Oqtane utilizes EF Core exclusively for its operational ORM support. In theory this means that Oqtane could support additional databases without much effort. However, Oqtane does not currently use EF Core for Migrations. Instead it uses a third party component called DbUp. DbUp relies on the execution of SQL scripts for creating and modifying database schemas. This approach does not adhere to Oqtane's Philosophy of Managed Dependencies, nor does it easily support multiple databases. Therefore, Oqtane should adopt the Migrations approach. By default, EF Core expects developers to execute Migrations manually from their development environment. This is not the preferred approach for Oqtane as its goal is to streamline and automate these types of tasks as much as possible. As a result, Oqtane will need to execute migrations programmatically.
One of the features of Oqtane is that it supports both shared and isolated multi-tenancy within a single installation. In order to provide this feature it needs to be able to resolve the tenant based on the attributes of the web request being processed. This means that the DBContext is not static - it is configured dynamically. However, there are specific types of processes such as those which occur during startup or are the result of a scheduled job execution which are not invoked by a web request. In these cases the tenant needs to be resolved in a different manner. It is these types of scenarios which complicate Migrations and need a reliable solution.
Oqtane leverages the .NET Core Identity system for managing user authentication details. Luckily the .NET Core Identify system was designed to support multiple databases - it just needs to be configured correctly. This configuration needs to integrate with the multi-tenant capabilities.
EF Core is an ORM that relies on models which are defined by the application. It is important that Oqtane contains a single set of models that are capable of being used by multiple database providers. In order to accomplish this goal, models must be simple and generic and avoid concepts that are not supported across different providers.
One of the other challenges in transitioning to this new approach is that module developers also need to have the ability to use Migrations when provisioning their modules. Currently there is an IInstallable interface which modules can implement to manage their schemas however most developers are currently using scripts because there is no defined pattern or example for using Migrations. Migrations for modules will need to be supported and once the pattern is established, module developers can choose to replace their scripts with Migration logic.
Oqtane also supports an installation wizard which will need to be modified to allow the user to select ( and configure ) their preferred database engine. Oqtane also supports a "silent install" option where configuration is read from the appsettings.json file and the install wizard is bypassed. In addition, Oqtane's Tenant Management capability will need to be enhanced to persist the provider type for a specific tenant and the user interface will need to be updated to allow for entry. Each use case will need to be tested to ensure expected functionality and no regression issues.
Beta Was this translation helpful? Give feedback.
All reactions