I am researching options for Corda database upgrades and I am puzzled with two different approaches described for Corda Open Source
https://docs.corda.net/upgrading-cordapps.html#state-schema-versioning
vs Corda Entrerprize: https://docs.corda.r3.com/database-management.html.
In Corda Opensource it is suggested to create several mapped schemas on java side.
And on Corda enterprise it is mentioned that liquibase scripts are used to modify database part.
Are two of the options mutually exclusive? I.e. if I use liquibase to update schema there is no need to add several mapped schemas?
And if I use MappedSchemas in java side, I do not need the liquibase scripts?
Liquibase support is added only in Enterprise. To create tables in Corda Enterprise, you need to add Liquibase scripts which supports automated database versioning.
Liquibase is not supported in Corda Open source. In Corda open source you will define your tables as Hibernate JPA entity. The table gets created in the database as a Hibernate entity. Even if you add Liquibase script in Open Source, it will be ignored and Hibernate entity will be created instead.
Liquibase is added in Corda Enterprise which helps developers write database agnostic scripts and helps them with automated database migration/versioning.
Hope that helps.
Related
Please advise the modern architecture of ASP.NET WebApi application (better .NET Framework not Core) with the latest innovations. For example: Unit of work pattern, controller -> manager -> repository, Automapper, xUnit, Serilog or..., a reliable migration mechanism for Oracle - Liquibase or... Asynchronous execution - async / await.
Requirements: authentication - AD / Windows, DB - Oracle. If there are code examples it would be ideal
UPDATE 1
What about ORM and migration system. In my opinion code first approach and EF migrations is good because the model suit to DB copletely, but it is risky. Previously I made Database Project for MS Sql Server and all change scripts was generated by comparing schemas of original DB and DB changed by EF migration, like this:
create models
apply migration to local (dev) database
compare original DB and changed DB, ectract/generate change SQL scripts
create deployment migration for CI/CD (DB project, liquibase or similar)
rollback local DB and test deployment migration
commit and push
It looks strange, but practice shows that using EFs migrations leads to data loss
For me, an API (which your app exposes to consumers) can be thought of as just another type of presentation layer.
If you assume that's the case then any sensible .Net architecture would suit. Personally I follow an logical approach like this: 5 layer Architecture - https://morphological.files.wordpress.com/2011/08/5-layer-architecture-draft.pdf
Not sure if that answers your question though. I think if you get the logical architecture sorted out, then determining which technologies you use to implement isn't so hard.
The 5-Layer architecture referenced above uses dependency injection, so you can use whatever database technology you like.
Use of sync vs async depends on the nature of the actual functional and technical problems you're trying to solve.
I'm using EF Core to access CDC tables within system tables in SQL Server, but command ef scaffold does not find the tables. I do access tables out of system tables successfully.
I've tried to grant table to dbo owner, without success.
Stack
SQL Server 2016
EF Core 3.1
I don't think you can use the CDC tables directly, and I would probably recommend against it since they can change between SQL Server versions.
If you really want to use them, you could create one or more views over the top of the CDC tables and use them instead. That way EF will pick them up and they are somewhat future proof if the tables change since you only need to change the views instead of fix and recompile your code.
Hi I have source SQL DB and destination RDS PostgreSQL DB.
I want to migrate by using flyway. First is it possible ?
If possible then can anybody help me with solutions?
Flyway is a tool for running scripts, rollbacks, targeted piecemeal deployments, all sorts of other stuff. However, it doesn't generate scripts. You have to provide it with syntax appropriate to the database system you're deploying to. T-SQL isn't the same as PostgreSQL. Nothing in Flyway will allow you to translate the T-SQL. You will have to do that work on your own. Once completed though, Flyway will absolutely be able to deploy those changes to your new database.
I'm trying to connect these two, but there is no information about it in here, does anyone have working example?
Symfony is agnostic of your persistence system. You can use PDO directly to connect to your Firebird database. Create the appropriates services using the Dependency Injection component to do so.
Alternatively, there is the Doctrine ORM. This library is often used with Symfony because it is installed with the Symfony Standard Edition. Doctrine doesn't support Firebird yet. However, there is a pending Pull Request adding support for it: https://github.com/doctrine/dbal/pull/838
You may try this fork for your project (at your own risk, it's very experimental) and help to finish the Pull Request to get it merged in the upstream project.
I found this comparing databases and genrating sql script using liquibase
and I was wondering if how I can do the same with Flyway.
1.- Generating sql script from the differences between tow databases.
Thanks!
There is an option if you use IntelliJ IDEA. Install JPA Buddy and follow this video:
There is no built-in functionality to do this at this point.
You can use any tool able to do database comparison and generate SQL: Oracle SQL Developer, TOAD, Squirrel SQL, etc.
Liquibase could make the diff from current database (e.g: product) and reference database (e.g: development), but unfortunately, it only works in the same database type, not cross databases with problems: Java Hibernate, Liquibase supports cross databases and SQLite?