I am wondering if and how OpenAccess ORM supports three challenges that probably every software vendor encounters with every single software-release in an enterprise-environment:
It is usually required that a software that is delivered must have at least the following three capabilities:
1. Environment independence
2. Security
3. Migration with rollback-capability
ad 1) A software is always delivered as one single, self-contained file (e.g. a zip file) which contains a) the software, b) installation instructions and c) migration scripts. This package must run on every environment the system consists of WITHOUT MANUAL ALTERATIONS. That means: the same software package can be deployed on the development environment, the system test environment, the test environment, the cluster test environment, the performance test environment and the production environment. So a software like OpenAccess ORM must make it easy to somehow support the need for multiple connection strings etc. (one for each environment) that can be switched without editing a file manually. Is that possible? How?
ad 2) Passwords are never ever allowed to be part of any software delivery. So it is never allowed to have a config file for an ORM that contains a password. Especially if you take "environment independence" into account: it can never contain a config file with multiple connection strings and multiple passwords. How can that be achieved?
ad 3) How does OpenAccess ORM support schema migrations, data migrations and migration rollbacks? Example: you have a table "stuff" which has a field "status" which has only 2 possible values: A=active, C=closed. In the past couple of months, the customer has filled that table with 100GB worth of data. Now you are supposed to deliver the next release in which you are supposed to replace the field "status" with "status-id" which refers to a new lookup-table "status" which has the fields "status-id" and "status-description". Let's say you have updated your domain model in OpenAccess ORM accordingly: how is the rollout and migration supported? At least one needs a script that
* adds the table "status" to the schema
* inserts the values that one needs to begin with (the lookup values for status)
* adds the field "status-id" to "stuff"
* performs a migration so that all existing entries in "stuff" actually use the new status-id field
* deletes the field "status" in "stuff".
and a script that rolls back this entire migration in case something fails and production needs to be rolled back to the previous release.
Does OpenAccess ORM create such scripts automatically or semi-automatically? How is that done?
Thanks
Matt
1 Answer, 1 is accepted
Thank you for your interest in OpenAccess ORM.
Here is some information regarding the three key points that you are interested in:
1) As far as the connection string is concerned, it is configurable exactly as if you are using ADO.NET for data access - you can have it in code, handled by custom logic, or in configuration files, so that it can be setup by your installation. Furthermore, the backend settings of your data context are now fully configurable through the application configuration file, so that you can additionally make changes when required.
2) You can use windows authentication for connecting to the database, or you can encrypt your connection strings so that the passwords are not visible in the configuration file. One detail in case you choose to use our Visual Designer, rather than the code only approach, is that the connection string is currently stored by default in your .rlinq file for clarity. However, before deploying, you can remove this connection string from the rlinq file (which is in XML format, so you can easily change it), without causing any issues.
3) OpenAccess ORM contains a mechanism of applying schema changes automatically during runtime, based on the current metadata defined either through Visual Designer or Fluent Mapping. However, not everything is supported:
- we are not dropping any objects, or renaming them. You can only change types and add new tables or columns.
- lookup tables creation is not automated - this is something you will have to write code for.
I hope that information helps you in evaluating the product. In addition, you can refer to the overview of all the key features that we are offering and post in our forums any feedback or questions you might have.
Ivailo
the Telerik team