Hello Justin, JCC> I believe migrations were inspired by the Ruby on Rails way of JCC> doing things, so it would be nice to stick to this if possible JCC> (of course, your way may be completely compatible for all I JCC> know). In the past, the migrations have been tidied up simply by JCC> bunching all the oldest ones up into a new 000 migration.
It is compatible, and the idea is just the same. What's changed is the format of the migration files: instead of having all those 0nn_RegionStore.sql scattered around, you'd have all the same stuff in a single file, separated by ":VERSION nnn" like this: :VERSION 1 create table .... () :VERSION 2 alter table ... add .... :VERSION 3 ... The advantage is that this way the history of changes is much more readable, you don't need to hunt around to see what was the next change. And if there are still any old-style migration files (with higher version numbers) left behind, they are processed too. If the same version section exists both in the new-style file and as a separate old-style migration, the latter is ignored. JCC> It would be very good to update nunit - just today I was looking JCC> to use the throws assertion before realizing that it was only JCC> implemented in nunit 2.5. It would be especially nice to see JCC> this work as patches, preferably separating the nunit upgrades from any other new tests. Justin, would you please just look at my repo just once and see the amount of changes there? And there is still local stuff I haven't pushed yet, such as unified data tests (that don't require separate test projects for each supported database), *fully tested* EstateStore, including the MS SQL part which was very unfinished. Right now I'm going through the RegionTests (also for all 3 DBs) and some of the tests looks rather messed up, so about half of them show up red in NUnit. Either I'll finish that and move ahead to other things (such as the Inventory store), or I'll be stuck forever with the Mantis thingy. And if you'll ever want to upgrade to the most recent MySQL .NET connector (which I did because I needed it to work correctly with stored procs in migrations, which in turn I needed for server-side tracking of asset access times), you'll see that nothing works, because the connector now treats CHAR(36) as Guid by default and a lot of type conversions in the code are broken. That requires safer conversions to/from DB types throughout the data layer, basically a way to guarantee that whatever the storage format is (esp. for UUIDs and bools), in whichever dbms, it gets read correctly. That already works in my version of the AssetStore (for all 3 DBs), but needs to be done in other stores as well. I checked that this works by changing ID/CreatorID in the MySql [assets] table between BINARY(16) and CHAR(36) and the thing kept working without any changes in the code. BTW, do you know that when working with a local MS SQL server, keeping the connection open and properly preparing all statements (once, not on every call) increases performance more than twofold on read operations (such as asset access)? The code that works this way (currently for assets, for all 3 DBs) and is fully tested, including performance tests, is also in my repo. Admittedly, the "master" branch of my repo is not all ready for integration and may be difficult to read (although most of it is tested and works fine). On the other hand, the smaller single-feature branches I mentioned in my previous msg are specifically made to be easy to pick up. If you want the NUnit update, it would take you about 3 mins to cherry-pick a couple of commits from "git at github.com:AlexRa/opensim-mods-Alex.git". Those are on the "migration-tests" branch with IDs: bdd430920d1... (corrections to the code - NUnit.Framework.SyntaxHelpers removed) af4ace4f6758... (the updated NUnit dll) You'll have to install a fresh NUnit distro as well, obviously. Best regards, AlexRa _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
