we have a big monolithic project that use EF to manipulates a database.
Now I want to start to create different services or micro-services that use a part of the big-model.
As first step read-only data may be good, but I have to reference all big-model or there is some different way ?
Any help are wellcome.
You can start with all the microservices sharing the same large DbContext, and maintaining the single shared database. This allows you to build new services without complicated refactoring of the existing application or database schema.
Related
We have a DB2 database which is used by legacy applications that we are in the process of decommissioning and we have an Oracle database that we are developing new applications for. In order to maintain compatibility with legacy applications until they are completely decommissioned and keep data in sync, we are using Atomikos for two phase commits. This however is resulting in a lot of duplicated entities and repositories and thus technical debt, because the same entities and repositories cannot be used by the same entity managers so we have to duplicate them and put them under different packages for the entity scanning.
In most cases we want to read data from the legacy database and persist to both, but ideally this would be configurable.
Any help on this would be greatly appreciated.
As a webapp novice, I'm not sure if I need to define models.py.
I already have a working Postgres database on Heroku that I've linked up with Postico and pgAdmin. Using these GUIs, it seems I can get and post data, and make structure changes very simply.
Most tutorials seem to glaze over the details and reasoning for having a models.py. Thanks!
Web frameworks typically enforce or encourage a Model-View-Controller (MVC) patterns that structures code such that the database code is kept separate to the presentation layer.
Frameworks like django come with and are more integrated with ORM functionality which is used to implement an MVC framework. The ORM allows you to programatically interact with your database without having to write sql code. It can let you create a schema as well as interact with it by mapping programming classes to tables and objects to rows.
Flask can be distinguished from many other web frameworks, like django, in that it is considered a micro framework. It is light weight and can be extended by adding extensions. If you need the database integration then you can use it with an external ORM tool like sqlalchemy (and optionally flask-sqlalchemy extension). You can then define a sqlalchemy model, for instance, in a file called model.py or schema.py, or any other name you find appropriate.
If you only need to run one or two queries against an existing postgres database and feel you have no need for the use of an ORM, you can simply use flask with the postgres driver and write the sql yourself. It is not mandatory to have a model.
A model/ORM can be beneficial. For example if you want to recreate an integration/test instance of the database, you can instruct the ORM tool to create a new instance of the database on another host by deploying the model. A model also provides a programming abstraction to the database, which in theory should make your code more database independent (well in theory, its hard to achieve this as databases can have subtle differences), and should make your code less tied to a specific database solution. Also, it alleviates the need of writing a language within a language (sql text strings within python code).
I'm starting a new project and I want to use AngularJS as Frontend and SailsJS as Backend. I have a requirement to separate databases for different clients. So, each client must have its own database.
I didn't find how to make this in Sails and Waterline. Does anybody know how to do this?
I have to change schema(or database) in runtime.
Right now, Sails does not have support for multi tenant databases.
It all depends also how many customers you have.
One approach that you can do (as with any other framework/language) is having (at least) one instance of your application pointing to different database configurations. Then have different domains for each customer. This involves creating a new "domain" per customer.
Another approach (that involves more coding) is to have the concept of an Organization entity that owns every object and include that on every filter.
There has been some PRs in the past about it but didn't move forward.
I have an application that uses Entity Framework code first migrations where the application is deployed on two servers both using the same database. Now I have a simple database update where a table and the EF model has a new column/property. I have created the migration and it works fine in a one server scenario.
But how do I deploy this to two servers without downtime? Without EF I would just start out and add the column to the table and then update the servers one by one. The old app would work just fine against the updated database as long as it is a simple change like this. What is the best way to do this in EF? Can I avoid problems in the second, not updated server, while I am updating the first one and the database?
This sounds like a perfect candidate for a Mirrored database, assuming you are using SQL Server.
You'd just apply your migrations to the Principal database and it will take care of the rest behind the scenes.
We have a couple of large, mature apps installed in hundreds of medical clinics. These apps are built using Windows Forms and WPF and although we host the database for some of them, the majority of our clients have a local install of the database.
We are in the planning stages of rebuilding our application on the ASP.NET MVC platform using Entity Framework. We will also be re-architecting our database, but for reference, the current database has about 600 tables and 1900 stored procedures. Although we don't have an official DBA, we have enough DBA skills to build and maintain what we have, so we are capable of designing and building the data model ourselves. Also, we will continue to have both on-premise and hosted solutions.
Our struggle is with deciding how to use EF. We're all in agreement that we should use code-first, but some of us think we should build our classes, decorate them with attributes, and allow EF to generate the database for us. Others think we should design and build the database and then generate code-first POCOs.
Assuming we will have non-CRUD stored procs, triggers, views, stored procs, and user defined functions, is database generation a reasonable approach? Are there reasons why it might be the preferred approach? Any good reasons for avoiding it altogether?