Massive, a small, happy, dynamic MicroORM for .NET that will love you forever

Massive was started by Rob Conery and has been transfered to Frans Bouma on March 4th, 2015. It's a small MicroORM based on the Expando or dynamic type and allows you to work with your database with almost no effort. The design is based on the idea that the code provided to you in this repository is a start: you get up and running in no-time and from there edit and alter it as you see fit.

Current Status

Massive is currently on v2.0. To obtain the old v1.0 code, please select the v1.0 branch in the GitHub menu or click here.

Installation

To use Massive in your project simply download the following files from the repository's src folder:

• Massive.Shared.cs
• Massive.YourDatabase.cs, e.g. Massive.SqlServer.cs for SQL Server
• Massive.Shared.Async.cs, if you want to use the Massive API asynchronously. Requires .NET 4.5 or higher.

Due to its design, all files share the same namespace. If you need to use more than one database in your project, you have to change the namespace of the files and use per database a version of the Massive.Shared.* files.

Requirements

Massive has no external direct dependencies, just get the code, compile it with your project and enjoy. It does have an indirect dependency, namely on the ADO.NET provider of the database used. The ADO.NET provider is obtained through .NET's DbProviderFactory system. This requires that the ADO.NET provider has been setup properly so .NET can find the factory needed. The following ADO.NET providers are supported out of the box.

• SQL Server. The ADO.NET provider ships with .NET.
• Oracle: ODP.NET. The installer for ODP.NET v12c installs both a full managed ADO.NET provider and a wrapper around its Java based Client Level Interface (CLI). By default Massive uses the latter, using the factory name Oracle.DataAccess.Client. If you want to use the Managed provider, please change the value in property DbProviderFactoryName in the Massive.Oracle.cs file around line 297 to Oracle.ManagedDataAccess.Client. This requires .NET 4.0 or higher.
• PostgreSQL: Npgsql. The Npgsql distribution contains an installer, offered at the 'releases' section. This installer will add the required DbProviderFactory reference and will add the npgsql dll to the gac.
• SQLite: Massive uses the official SQLite .NET provider. Please read the official documentation on that provider to get started.
• MySQL: Massive works with the Oracle/MySQL ADO.NET Driver (MySql.Data.MySqlClient) and with the Devart dotConnect for MySQL driver (Devart.Data.MySql). Be aware of licensing issues. At the time of writing the free version of the Oracle/MySQL driver must not be used in closed source development, though it can be used in many open source contexts. However the free version of the Devart driver can be used in closed source development subject to some restrictions. If you want to use the Devart driver, please change the value in property DbProviderFactoryName in the Massive.MySql.cs file around line 280 to Devart.Data.MySql.

Migrating from v1.0 to v2.0

If you're using v1.0 currently and want to migrate to v2.0, please take a look at What's new in v2.0 page for more details about whether you'll run into the changes made. In general the breaking changes will be minor, if any.

What's new in v2.0

Besides some changes as documented in the What's new in v2.0, the following features / additions are new:

• Async / Await support. Not all supported databases support asynchronous data-access under the hood, but the Massive API at least allows you to work with the code asynchronously. Full Async is supported by the ADO.NET providers of SQL Server and Npgsql (3.x). ODP.NET (Oracle) doesn't support async under the hood so using the Async API with Oracle will still use synchronous data-access under the hood (through the default DbCommand fall back code). SQLite's ADO.NET provider does support async using specific types but Massive doesn't support these.
• Shared code. In v1.0 code which was effectively the same among all supported databases was copy/pasted, in v2.0 Massive uses partial classes and shares as much code as possible among all supported databases.
• Unit Tests. In v1.0 there were no tests but in v2.0 we properly implemented a series of tests to see whether things indeed work the way they do. They can also be used as an example how to get started.
• Culling of dead code.

Contributing

If you want to add new features to Massive or have a fix for a bug, that's great! There are some rules however and if you don't meet them, I won't merge your code, no matter how long you've worked on it. This is nothing personal, and to many of you these rules might sound rigid, but this repository isn't a playground for newbies: the code is used by many people and they depend on it. It therefore has to be of high quality and changes made to the repository will live on forever so they aren't accepted without review.

• PRs which are solely about whitespace changes are ignored.
• Before sumitting a PR, first open an issue and discuss your proposed change/feature there. This is mandatory. Any PR without a linked issue is closed without comment. The main reasoning behind this is that it prevents people wasting time on things that will never make it into the code base or that e.g. a PR requires refactoring before it's being accepted because it doesn't fit into the codebase. ORMs, even small ones like Massive aren't simple: there are a lot of pitfalls and in general non-ORM devs overlook a lot of them. Discussing a change before a PR is a good thing in this case. Also don't be afraid to ask if you don't know how to proceed: that's why the issue is opened.
• If your PR contains submissions from others, I can't accept your PR: a committer owns the code of a change. If you commit code into Massive owned by others, it is unclear those others were willing to share that code with the main repository.
• Don't change the API nor its current behavior. Massive doesn't have a fixed version number, and is distributed through text files, but I still want the API to be dependable: no method is removed nor has its signature changed. For instance if you want to add functionality to a method and it requires extra arguments for that, you have to add an overload of the method, you can't simply append arguments to a method's signature. Be very careful here. Adding a new overload to a method which has a params argument at the end can easily break existing code (by causing it to unintentionally compile against your new method instead of the params version). Even simply adding optional parameters to the end of an existing method will break the API, since code which is linked against a pre-compiled version of Massive will fail. I cannot accept changes like this.
• Tests are preferred. If your change can be tested with the current tests, no new tests are needed. If your change requires additional tests because the current tests don't cover it, add them with your PR.
• If possible support all databases supported by Massive. I've designed Massive in v2.0 to share as much code as possible across all supported databases. New submissions are required to follow that pattern: for instance large pieces of code specific for SQL Server which are also usable with some tweaks on Oracle are not accepted. Instead the code has to be made generic and added to Massive.Shared, using methods implemented in the specific database partial classes to configure the code for that particular database. This can be a great pain, e.g. because you don't have access to Oracle nor Postgresql. In that case, request what you should add for these databases or that I do that for you and test the changes for you locally using the tests you wrote.
• No new files please. There's currently a Massive.Shared.Async, and the sooner I can merge that into Massive.Shared, the better (MS still supporting .NET 3.5 is currently the limitation on that, but it's likely it will be merged in the near future).
• Code defensively. If your code accepts input from the user, be absolutely sure this input is passed on as parameters and user crap like null values and name mismatches are covered. You don't need to throw a myriad of exceptions, but at least make a bit of an effort.
• If it takes less time for me to write the code myself than to look at your PR, tell you how to change things and go into an endless bikeshedding debate with you, chances are I'll write it myself instead of debating things with you.
• If you add to the API, it's recommended you add a small example to the documentation in this readme below. Some people think tests are documentation, but tests are tests, they test things. Documentation document things, so it's preferable to have documentati