The sql command timeout setting of 0 (zero) appears not to work. Users must set a value > 0. The 0 value appears not to be passed to the Enterprise Library, only values > 0 are passed.

If this is the case, then users are unable to set an infinite command timeout value in Easy Objects

The workaround is to set a high value for the command timeout

Wow. I have to say that I never thought I would be writing this proposal. Having considered EasyObjects a dead project, and long surpassed by other ORM platforms in both features and usability, I wasn't sure in what ways EO could still add value to a development project.

But recent changes in the .NET landscape have caused me to re-evaluate old concerns. The move to netstandard is indeed most interesting by itself, but the implications for EasyObjects are many as well. In order to move forward, I am proposing the following changes to EO:

Requirements

• Since the Enterprise Library is not supported on netcore, propose that EO move over to Dapper for database operations.
• Since MyGeneration hasn't been updated in a while, propose that EO move to T4 templates for code generation. If T4 isn't sufficient, then CodeSmith would be the second choice (purchase required).
• The original EO implentation relies on a backing store of a DataTable for most operations, propose that EO move to POCOs for all operations to line up with Dapper's ability to hydrate query results into existing classes.
• Based on a .NET 1.1 standard, the original EO implementation did not have true support for nullable types, using instead the DataTable's support for nulls. Propose that EO now support nullable types in the generated POCO classes.
• Propose that, for now, EO drop support for the following:
  • Oracle
  • Stored procedure generation (EO will still support calling stored procs, we just won't generate them)

Exploratory items

• Add support for dependency injection of query generator. Since the query language is specific for each database EO will support (T-SQL for SQL Server, PL-SQL for Oracle, etc.) it would be nice to inject the query language dynamically at runtime.
• Built in support for System.Transactions

I'll update this proposal as I think of more items. Additional comments welcome!