Is there a standard way in symfony + propel to manage changes to the database model in a situation where
the application has a number of separate variants (one for each specific customizations):
core application: code + datamodel
|- variant1: specific code + specific datamodel changes
|- variant2: specific code + specific datamodel changes
...
mulitple developers work at separate parts of the application and therefore also at separate parts of the datamodel
Problems happen e.g. when parts of the datamodel are interdependent (foreign keys) and developers write migrations and oversee these inderdependencies. And since the variants are parallel to each other it becomes increasingly difficult and error prone to keep trak of and write migrations.
I know that this is a what management is all about, but I'm wondering whether there are automatic? ways (- or completely otherways not using propel or using subversion etc. to make checks) that make sure that problems are reduced, ideally to zero.
Basically, I would like to know if there are enterprise grade practices / standards for using symfony and ORM (for symfony 1.4 or 2; propel) that manage multiple developers + multiple variants of the application?
Thanks :)
Propel2 supports parallel migration, means you can have different migration files in different development branches.
So you're just creating migration files based on your changes and new code as usual and commit all that stuff which results basically in having some migration files in branchA and other in branchB. When a branch will be merged to master you can just call the migrate:migrate command at master and are ready to go.
When you switch from branchB to branchA you need to make sure to downgrade the migration in branchB until you have the same base as branchA. Then switch the branch to branchB and do migrate:migrate.
Related
Say I'm going to create few microservices: Alpha, Beta, Gamma.
In terms of Application structure using older Symfony version like 2, I'd create a bundle for each service, but bundles are no longer recommended in Symfony 4. So... Should I create separate repositories for every service or still create a bundles in a one App?
If you have different microservices, as in different applications, you will not need bundles. You can keep them in different repositories, but a common practice is to use a so called mono-repository. As the name suggests, with a mono-repository you keep all of the projects in a single repository. This has the benefit that changes spanning all projects can be done more easily and in sync. The drawback is that it requires more effort when managing and might cause additional overhead when building and deploying as it will not be easy to see which service has changed so must likely you rebuild all of them. There are a few books and presentations on mono-repositories you might want to check out. In short, Symfony does not restrict how you manage your services. You can have a single repository for all projects or multiple repositories.
If you want to serve all "services" through the same application, even without bundles, you can do so by using namespaces to separate the logic, e.g. for controllers:
my_app
- src
- Controller
- Alpha
- IndexController
- Beta
- IndexController
This should work out of the Box with the default configuration and even if you deviate you can make things like argument resolvers work by just pointing the configuration to the correct folder. Obviously this will require you to make sure that code is not shared between services should you ever want to extract them into their own application. There are some static code analyis tools that help you with keeping your architecture clean, i.e. make sure Alpha does not use code from Gamma and vice versa.
If you want to separate the apps more clearly by doing something like this:
my_app
- src
- AlphaApp
- ...
- BetaApp
- ...
You can still do that but it will require more manual work and the recipes will not work anymore, requiring you to do manual changes to most configurations and moving around files. How to do it depends on whether you want a shared kernel or a separate kernel for each service, but if you go that route I recommend keeping separate projects in the same repository, as it will probably yield cleaner results and be less work.
You can still create bundles in symfony4 though its not recommended by best practices. see https://symfony.com/doc/current/best_practices/creating-the-project.html
In meteor, I can have multiple client, multiple server directories, etc. (ex: /foo/client/ and /bar/client/) I segment my app by behavior, for example /users/* for user management, subs, methods, UI, etc., or /inv/* for inventory management, collections, subs, methods, UI, etc., and all other parts of my app. This allow some code organisation and separate components and methods so the app will scale better in the long term.
This works quite well so far, however I need to add some assets to each segments of the app and, since the /public directory content is copied over /.meteor/.local/build/programs/web.browser/app, I wanted to know if it was possible to have multiple public directories, where all files would be merged into the build target?
No it isn't currently possible to have multiple public directories within a single application. This is disallowed by Meteor's Isobuild system. If you want to maintain separate /public directories with related component functionality, then you should look into leveraging Meteor packages. Packages can have their own public assets. The "Building Large Apps: Tips" hackpad talks about how you can leverage a "packages-for-everything" approach with Meteor and achieve the type of component separation (with separate public assets) you're looking for. That being said most of the Meteor community has either moved, or is starting to move, away from a "packages-for-everything" approach. The launch of Meteor 1.3 and ES2015 module support has made this approach mostly unnecessary (with a few exceptions, like maintaining separate public assets).
Up until now I have been using the EF Power Tools beta to do this. I click on an empty project, select EF and then reverse engineer.
The PowerTools creates all the model tables and EF mapping tables for me. It's something I do quite often when our database changes and I need to see how the mapping classes have changed. It's not completely necessary but it saves a lot of work and makes life very easy.
From what I understand is this was added to EF6.1. However where ... ?
All I see from the demos is that now I have the ability to start from a database and generate code first. For this it seems I would have to create a new application and do a lot more. I miss the two click functionality of not being able to create the mapping tables.
Does anyone know if this is still available and if I just missed it. If not available then time to go back to EF Power Tools beta :-(
Install the EF 6.1 Tools from MS downloads, and add a new "ADO.NET Entity Data Model" to your project, and you will have the new option to generate "Code First from database" https://entityframework.codeplex.com/wikipage?title=Tooling%20Consolidation
So I have written a fairly simple DataAccess Layer for use with Umbraco CMS 4.9. I want to write some Integration tests to test that my repositories work etc.
Obviously Umbraco has some dependencies, so how do people test that their data access works normally?
p.s We already have BDD / selenium tests..I want proper Nunit Integration tests...
One approach might be to fake the source data, i.e. the nodes themselves. Obviously it would be a fair bit of work to set up a data tree, but because the Node object inherits from INode, you should be able to inject your own object implementing INode and create your own data tree for all the unit tests to use.
What method do you use to get a compile time error when the database schema changes occur in an ASP.NET project?
For example, if you have a GridView bound to a DataSource, I can only get runtime errors when a schema change occurs, not a compile time error. Intellisense works fine on the code behind using datasets, LINQ, etc, but I cant seem to get a compile time error on an ASP.NET page when I change the schema.
Any advice?
Create a unit test that verifies the correctness of you data access layer, and make sure it covers all your DB-related code. Not everything can be caught at compile time...
One way I can think of easily achieving this behavior would be to databind to a dynamic DAL. There are some tools that can help do this DAL generation, I'd recommend taking a look at SubSonic.
Once you have something like SubSonic in place you can bind to the resulting business objects. These business objects will automatically change in the case of a schema change in the database and this will break your binding code which will result in a compile time error.
Update
Assaf's recommendation to use Unit Tests is also a good idea. It doesn't solve your stated problem but it is definitely something that should be in place and is a great tool for flagging these type of problems.
We use a modest system (xml to c++) to create schemas from an independent description, this system also creates names for tables and columns that we use inside the code, when there is a change in the schema the names change, as the names we originally used are not there anymore and the compiler will flag an error.
You could probably configure a lot of the DAO generation tools to do something similar.
One solution would be to version your database and map an application build to a specific version (maybe in a properties file). In the entry point of your app, you can compare the expected version to the actual version and handle the error accordingly.
I'm not sure whats the equivalent in ASP.net of Migrations in Rails or dbdeploy in Java for versioning your database. But any DB versioning tool that makes schema changes incremental and versioned and tracks the version in a Version table will suit the purpose.
But if you want a compile time error while building your app, you might as well upgrade your schema to the latest version as part of your build process, avoiding the possibility of schema changes in the first place.