@fguo - the best way to get a complete example of how this works is to generate an entity using the RAD tool and select your primary key type. it will generate all of the code you need to work with long of Guid. Simply mimic the code generated in your own code.
I'll try that later. In the meantime grow your arms or shorten your pockets so you can buy a beer. And stop taking life so seriously, it's there to be enjoyed.
India Pale Ale, good choice! Brewed to keep the troops of the East India Company sober instead of drinking the local loopy juice, to keep the holds of the clippers full when returning to the Jewel of the Empire and strong enough not to go off on the way! Good man, enjoy your weekend.
Whose turn is it to get the beers in?
@strix20 Great, just give me the option to test using a database with persisted data! That way @ManojReddy can see the results of the test and create/read/update/delete to his heart's content! Jeepers, you wouldn't honestly expect a test to connect to a production database? I recommend that developers should never even know the meaning of the word production unless the word can be used in the same sentence as "whose turn is it to get the beers in"?
@ismcagdas - ditch the modals! ;)
I'm with @BBakerMMC. Everyone seems to be fixated with code-first and the database seems to be downgraded to something which just works. The old adage "rubbish in, rubbish out" should be applied. Testing without a database only tests "rubbish in". Testing against a database allows a DBA to review and change column ordinality (key for user reporting and queries), check column nullability, data- types and then we start to look at replication, database mirroring, recovery procedures etc etc etc. The job doesn't just finish when the input procedures work. For many companies now the key asset is data (include all telecoms companies and ISP's, content providers etc etc). By the time we start to bang badly formatted data into Hadoop and then apply map reduce functionality the consequences of requesting change can be dire. To give a simple example, restricting testing to use in-memory processes such as SQLite means we have to use the dbo schema in SQL Server/Oracle. Most professional DBA's would tear their hair out if they were told that tables have to be created in the dbo schema and prefixed to show that they belong to a particular area of functionality. That restriction alone removes a whole cart load of tools from the DBA's toolbox. I would respectfully suggest an option to use Sqlite or SQL Server/Oracle/MySQL (etc) for testing as a configuration option. Having said that the example unit tests provided by the Zero guys provide an excellent starting point for convention and procedure, well done guys!
@ismcagdas, I think dynamic forms would be an excellent feature addition but it's a big topic. Vlad quite rightly points to [https://www.google.co.uk/forms/about/]) as a great example. In my case I am building forms grouped into templates for different scenarios (care actions, quality inspections, ISO reviews, site audits etc.) which are saved as JSON objects in the database. These forms can then be delivered to the client (in my case an Ionic app) and the JSON is dynamically rendered as a form. The form is completed on the client and the results are displayed in Zero. Please try and avoid the word survey which appears to have become de rigueur when describing dynamic forms. Every time I see this I end up reading about how someone has implemented another list of questions and answers usually using checkboxes.
Vlad, Dynamic forms, eh? We seem to have a lot in common!
Vlad, If you find an answer to that one let me know.
