Skip to content
Snippets Groups Projects
Commit 873acad2 authored by Marcel Nellesen's avatar Marcel Nellesen
Browse files

Merge branch 'Hotfix/909-defaultQuotaWorks' into 'master'

Hotfix/909-defaultQuotaWorks

See merge request coscine/cs/database!87
parents 67ffefb2 44a1ad5d
No related branches found
No related tags found
1 merge request!87Hotfix/909-defaultQuotaWorks
## ESLint Convention
Make the changes to the code and tests and then commit to your branch. Be sure to follow the commit message conventions.
Commit message summaries must follow this basic format:
```
Tag: Message (fixes #1234)
```
`Tag` should not be confused with git tag.
`Message` should not be confused with git commit message.
The `Tag` is one of the following:
* `Fix` - for a bug fix.
* `Update` - for a backwards-compatible enhancement.
* `Breaking` - for a backwards-incompatible enhancement.
* `Docs` - changes to documentation only.
* `Build` - changes to build process only.
* `New` - implemented a new feature.
* `Upgrade` - for a dependency upgrade.
The message summary should be a one-sentence description of the change. The issue number should be mentioned at the end. * The commit message should say "(fixes #1234)" at the end of the description if it closes out an existing issue (replace 1234 with the issue number). If the commit doesn't completely fix the issue, then use `(refs #1234)` instead of `(fixes #1234)`.
Here are some good commit message summary examples:
```
Build: Update Travis to only test Node 0.10 (refs #734)
Fix: Semi rule incorrectly flagging extra semicolon (fixes #840)
Upgrade: Esprima to 1.2, switch to using Esprima comment attachment (fixes #730)
```
The commit message format is important because these messages are used to create a changelog for each release. The tag and issue number help to create more consistent and useful changelogs.
Based on https://github.com/eslint/eslint.github.io/blob/master/docs/developer-guide/contributing.md#step-2-make-your-changes
[npm-image]: https://badge.fury.io/js/conventional-changelog-eslint.svg
[npm-url]: https://npmjs.org/package/conventional-changelog-eslint
[travis-image]: https://travis-ci.org/stevemao/conventional-changelog-eslint.svg?branch=master
[travis-url]: https://travis-ci.org/stevemao/conventional-changelog-eslint
[daviddm-image]: https://david-dm.org/stevemao/conventional-changelog-eslint.svg?theme=shields.io
[daviddm-url]: https://david-dm.org/stevemao/conventional-changelog-eslint
[coveralls-image]: https://coveralls.io/repos/stevemao/conventional-changelog-eslint/badge.svg
[coveralls-url]: https://coveralls.io/r/stevemao/conventional-changelog-eslint
\ No newline at end of file
## C# Database ORM and FluentMigrator
We provide a data model generated using linq2DB, allowing us to access our database via linq.
A migration tool based on fluent migrator is used for stable and reversible database migrations.
## Data Model
linq2db generates the code that eventually creates the data model by compiling a design time text template.
The main file for the text compilation is the /DataModel/CsDatabase.tt file. In that file, the database connection information should be provided. Follow the instructions in that file for working with the datamodel.
The data model will be generated on every build process for the project guaranteering an up-to-date state of the data model with respect to migrations. The builer in this case is MSBuild, which does not know relative paths used by linqToDB. That means, if, for instance, some library changes require changes to the text compilation process from the text templates, you need to register the path variables used by linqToDB by unloading and editing the CsDatabase.proj!
### Using the data model in your project
Other than including this project, you need to set the configuration string for linqToDb to establish a connection to your database.
You must call the constructor for the data model object with the server provider name and the connection string.
The connection string has the format: "Data Source={dbDataSource}; Database={dbDatabase}; User Id={dbUserId}; Password={dbPassword};".
The provider name is "SqlServer.2008" for our projects. A list of valid alternative names can be found here: https://linq2db.github.io/api/LinqToDB.ProviderName.html
For an example look at the unit test in CsDatabase.Tests/ModelTest.cs
### Changing the target of the data model
If you want to change the database for which the data model should be created, you need to make a few adjustments:
- The namespace should be adjusted in
- cs-database/DataModel/CsDatabase.tt
- cs-database/DataModelConstructor.ttinclude
- The name of the partial class in cs-database/DataModelConstructor.ttinclude
- The configuration string for the database connection will, by default, be fetched from consul. If needed, change the consul query keys in:
- cs-database/DatabaseConnection.ttinclude
- Migrator/Migrator.cs
- If you are connecting a database other than msserver, you also must swap the
It is recommended to include the cs-database/DataModelConstructor.ttinclude so that the database connection can be established with a programmatically obtained connection string (e.g. using consul) rather than having to include a App.config file to your projects.
- Furhtermore you need to adapt the right _providerName in:
- CsDatabase.Tests/ModelTest.cs
- your projects
## Fluent Migrator
The fluent migrator provides a command line tool for handling database migrations.
Currently, it provides an intermediary interface for utilizing the fluentMigrator up migration (down migration is currently not supported by us) as well as its rollback function, using the command line arguments:
```
-migrate_up
-roll_back <number of roll back steps>
```
FluentMigrator will look for migrations in the Migrations directory. While it is, in principle, possible to call the our migrator from other projects as well, it is recommended to have all migrations in this project for greater cohesion and in order to make sure that the data model stays up-to-date.
Migrations should be identified by a unique id which corresponds, roughly, to the date and time of its implementation. The format is:
```
YYYYMMDDhhmm
```
FluentMigrator uses this identifier to manage its migration versioning. For an example migration, check out the migrations in the test project for the database.
\ No newline at end of file
docs/images/add_a_package.png

19.2 KiB

docs/images/add_a_reference.png

21.3 KiB

docs/images/create_class_library.png

55.5 KiB

docs/images/create_project.png

59.3 KiB

docs/images/select_framework.png

33.2 KiB

docs/images/select_project.png

8.35 KiB

docs/images/test_code.png

85.3 KiB

It's very easy to make some words **bold** and other words *italic* with Markdown. You can even [link to Google!](http://google.com)
Sometimes you want numbered lists:
1. One
2. Two
3. Three
Sometimes you want bullet points:
* Start a line with a star
* Profit!
Alternatively,
- Dashes work just as well
- And if you have sub points, put two spaces before the dash or star:
- Like this
- And this
If you want to embed images, this is how you do it:
![Image of Yaktocat](https://octodex.github.com/images/yaktocat.png)
# Structured documents
Sometimes it's useful to have different levels of headings to structure your documents. Start lines with a `#` to create headings. Multiple `##` in a row denote smaller heading sizes.
### This is a third-tier heading
You can use one `#` all the way up to `######` six for different heading sizes.
If you'd like to quote someone, use the > character before the line:
> Coffee. The finest organic suspension ever devised... I beat the Borg with it.
> - Captain Janeway
[200~There are many different ways to style code with GitHub's markdown. If you have inline code blocks, wrap them in backticks: `var example = true`. If you've got a longer block of code, you can indent with four spaces:
if (isAwesome){
return true
}
GitHub also supports something called code fencing, which allows for multiple lines without indentation:
```
if (isAwesome){
return true
}
```
And if you'd like to use syntax highlighting, include the language:
```javascript
if (isAwesome){
return true
}
```
GitHub supports many extras in Markdown that help you reference and link to people. If you ever want to direct a comment at someone, you can prefix their name with an @ symbol: Hey @kneath — love your sweater!
But I have to admit, tasks lists are my favorite:
- [x] This is a complete item
- [ ] This is an incomplete item
When you include a task list in the first comment of an Issue, you will see a helpful progress bar in your list of issues. It works in Pull Requests, too!
And, of course emoji!
GitHub supports many extras in Markdown that help you reference and link to people. If you ever want to direct a comment at someone, you can prefix their name with an @ symbol: Hey @kneath — love your sweater!
But I have to admit, tasks lists are my favorite:
This is a complete item
This is an incomplete item
When you include a task list in the first comment of an Issue, you will see a helpful progress bar in your list of issues. It works in Pull Requests, too!
And, of course emoji!
## Add NUnit Tests
### Add Nunit test adapter
1. Choose **Tools > Extensions and Updates**
2. In the **Extensions and Updates** dialog box, expand the **Online** category and then **Visual Studio Marketplace**. Then, choose **Tools > Testing**.
2. Select the **NUnit test adapter** and then choose **Download.**
### Add Tests
1. Create a class library project and add it to your solution.
For convinience name it like your main project and add **.Tests** as a suffix.
![alt text](images/create_class_library.png "Select Class Library")
2. Install the plug-in. In **Solution Explorer**, select the class library project, and then choose **Manage NuGet Packages** from its right-click or context menu.
![alt text](images/add_a_package.png "Add a package")
3. In the **NuGet Package Manager** window, search for and select the plug-in (NUnit), and then choose **Install**.
![alt text](images/select_framework.png "Select Project")
The framework is now referenced in your project under **References**.
4. From the class library project's **References** node, select **Add Reference**.
![alt text](images/add_a_reference.png "Add a reference")
5. In the **Reference Manager** dialog box, select the project that contains the code you'll test.
![alt text](images/select_project.png "Select Project")
6. Code your unit test.
![alt text](images/test_code.png "Test Code")
......@@ -248,7 +248,8 @@ namespace Coscine.Database.Models
projectQuotaModel.Insert(new ProjectQuota
{
ProjectId = project.Id,
ResourceTypeId = resourceType.Id
ResourceTypeId = resourceType.Id,
Quota = 25
});
}
}
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment