So, Zend's phpunit database framework allows preloading a database with tables. However, this stops me from using #dataProvider with the database because it appears that #dataProvider gets executed before zend reloads the database. This causes the database tables to be out of sync.
Is there a way I can rearrange this procedure so that zend reloads the database, then #dataProvider gets called?
When does Zend load your database? If you call it specifically from setUp() you could move the call to the data provider method. It's not ideal, but the way that PHPUnit calls the data providers is pretty core to its architecture. Sebastian is planning to rework this as some point, but I don't know how high it is on the priority list.
Edit: Sebastian created a ticket that discusses reordering tests based on #depends--not changing when data providers are called. My apologies for the confusion.
Related
The normal way of dealing with Doctrine Migrations is via the standard Commands - during development one runs the commands manually to e.g. run diffs and apply the migrations, and deployment typically involves applying them the by the same approach but automatically. Occasionally when working in a team on a local instance there are new migrations, but I've updated my source from version control rather than done a deployment, so I need to apply the new migrations manually, and I need to know that I need to do that! An improvement could be to display a warning on a rendered webpage that migrations are out of sync and action needs to be taken.
Is there a way to access the Migrations API directly in PHP/Symfony code, so that I could detect a mismatch between committed and applied migrations? I haven't found any documentation about that. I've had an initial poke around the code and it seems heavily skewed towards Commands (reasonably enough).
Firstly, updating your source code from version control, is a deployment too, and applying Doctrine Migrations should be part of that. You should create a check list of all the steps you need to do during a deployment, including rollbacks. Depending on the complexity of the application, many things could go wrong.
To answer you question, you can execute, in your code, a diff migration with the Process component and parse the output to determine if there're migrations to be applied.
I am developing UWP application using vs studio 2017 version 15.9.6.
I want to use Windows local SQLite database. I want to run an SQL script named mySql.txt when the user first time install the application. I dont want to run it every time when the user run the app as it contain insert statement, which will cause duplicate rows insertion. So I want to run that script only once, preferably in the installation time.
How can I do that? I am very new to UWP and .NET. Please guide me step-by-step if possible.
You can make sure the initialization/seeding is done only once for the app. For that you may utilize ApplicationDate.Current.LocalSettings.
These allow you to write simple data for your application which are bound to your app. Once the user uninstalls the app, these data will be removed as well. This fits your scenario exactly.
Suppose your database initialization code is in the method InitializeDb(). You could use the following to make sure the initialization is done only once:
if (!ApplicationData.Current.LocalSettings.Values.ContainsKey("DbInitialized"))
{
InitializeDb();
ApplicationData.Current.LocalSettings.Values["DbInitialized"] = true;
}
This code first checks if we have initialized the db previously and if not, performs the initialization and stores a flag into app settings to make sure the next time the initialization is skipped.
You can run this code during app initialization, for example in OnLaunched method, or on when the database service is first required.
This is of course the simplest implementation, so you can (and should) add some exception handling, so that if the initialization fails, it can be retried and so on. Also you may want to handle app updates and DB updates - in which case you can use ApplicationData.Current.Version which allows you to track the version of application data and can be used to keep track of DB version as well so you can perform appropriate migrations between versions.
Finally, for even better user convenience, there is also a way to perform the app update steps during updates. See this article for more info.
I'm developing a windows application which uses SQL Server Database. I have different versions of this application and they have different database structure, so I need to migrate database to the latest version on application start. I want to compare the database structure with the application model, then do alter, create or drop commands.
Also I want to use EF Code-First ORM, after some search I've figured it out that there are some useful commands and configs in code first. But the problem is, as I know, all of them drop the existing database and create a new one so the data will be lost while I need the data.
I used these lines in my application start function:
var migrator = new DbMigrator(new Configuration());
migrator.Update();
But after execution this line I will get this exception:
There is already an object named 'SomeTable' in the database.
I know that, it's right and there is that table but in structure is changed! How can I compare the structure and do the rest?
That's not how migrations work. You need a migration for every version of your database so EF can check the __MigrationHistory table and see if it has been applied. If your initializer is set to MigrateDatabaseToLatestVersion your database won't be recreated on model changes.
You could try to recreate the history: roll back to your oldest database, add a migration, add 2nd oldest version changes, create a 2nd migration, etc.
Another option is to add a migration for where you are now, generate a script (update-database -Script) then comment out the stuff that exists in each deployed database before applying it.
Yet another option would be to use the VS Schema compare utility against each database and your current database to get the changes over. Then apply a baseline migration to each (add-migration Initial -IgnoreChanges).
Now moving forward you can generate a series of migrations and your code should work as expected.
I am having some problems while trying to create integration tests with Selenium and NUnit.
I'm trying to use Selenium RC in NUnit test to drive my ASP.NET web app, and would like the tests to actually do all the stuff in DB that the real user would do. Naturally it would be nice if the database could get rolled back after Selenium has done it's thing, and i've asserted that db contains the new rows (etc) with the data from the ui.
So, here's the setup i have (in some sort of pseudocode):
TestMethod()
{
Using(new TransActionScope)
{
Selenium.StartSelenium()
Selenium.SelectAndClickAndDoStuffInUI()
AssertSomething()
}
}
Now, the SelectAndClickAndDoStuffInUI-method clicks around in UI and thus fires up our proprietary da-framework. Our framework writes all the stuff into db, and the AssertSomething-method asserts that everything is fine in db. Framework uses transactions ("required") in it's inner workings.
So everything is fine, right? No, sadly not. The TransActionScope in the example above shouldn't get committed (no txScope.Complete()-call there), and thus all the inner transactions should get rolled back too, right? Well they do not, and everything Selenium does through the UI gets committed to DB.
I've really tried to understand where this goes wrong, but so far haven't found the answer.
Thanks for reading, and (finally) here's the actual question:
Why the TransactionScope does not get rolled back in the case shown in my example?
I will gladly provide additional information about the situation and setup!
You are using a UI to an asp app. That means your test is not able to rollback the changes you made.
The transaction scope can only work in your own process. How is the transaction manager able to undo the click inside a webinterface? It could be anywhere. Selenium is just remote controlling a browser.
You should create your "real" unit tests with mock objects, and not access the database at all. Its a little hard with a normal asp page, but you cant take a look at asp.MVC to find a possible solution to this problem.
I would like to find a way to create and populate a database during asp.net setup.
So, what I'm willing to do is:
Create the database during the setup
Populate the database with some initial data (country codes or something like that)
Create the appropriate connection string in the configuration file
I'm using .NET 3.5 and Visual Studio 2005, and the Database is SQL Server 2005.
Thanks in advance.
If you are creating an installer I'm sure there is a way to do it in there, but I am not all that familiar with that.
Otherwise, what you might do is the following.
Add a application_start handler in the Global.asax, check for valid connection string, if it doesn't exist, continue to step two.
Login to the server using a default connection string
Execute the needed scripts to create the database and objects needed.
Update the web.config with the connection information
The key here is determining what the "default" connection string is. Possibly a second configuration value.
Generally, you'll need to have SQL scripts to do this. I tend to do this anyway, as it makes maintaining and versioning the database much easier in the long run.
The core idea is, upon running the setup program, you'll have a custom action to execute this script. The user executing your setup will need permissions to:
Create a database
Create tables and other database-level objects in the newly-created database
Populate data
Your scripts will take care of all of that, though. You'll have a CREATE DATABASE command, the appropriate CREATE SCHEMA, CREATE TABLE, CREATE VIEW, etc. commands, and then after the schema is built, the appropriate INSERT statements to populate the data.
I normally break this into multiple scripts, but YMMV:
Create schema script
"Common scripts" (one for the equivalent of aspnet_regsql for web projects, one with the creation of the Enterprise Library logging tables and procs)
Create stored procedure script, if necessary (to be executed after the schema's created)
Populate initial data script
For future maintenance, I create upgrade scripts where a single script typically handles the entire upgrade process.
When writing the scripts, be sure to use the appropriate safety checks (IF EXISTS, etc) before creating objects. And I tend to make mine transactional, as well.
Good luck!
Well, actually I found a tutorial on MSDN: Walkthrough: Using a Custom Action to Create a Database at Installation
I'll use that and see how it goes, thanks for your help guys, I'll let you know how it goes.
If you can use Linq to Sql then this is easy.
Just import your entire database into the Linq to Sql designer. This will create objects that describe all objects in your database, including the System.Data.Linq.DataContext derived class that encapsulate the entire database setup.
Now you can call DataContext.CreateDatabase() to create the database.
See here more information.