I don’t mean to conflate the issues I had with EFOracleProvider with the issues I had with Entity Framework. I fully recognize EFOracleProvider as completely alpha, untested, non-comprehensive code. But I take issue with the difficulty with which Entity Framework finally clicked for me, including the need of a command-line based utility to generate code, the three separate metadata files, and so on. This is why I mention Ruby at the end of the post. Independent of the database, there are ORMs that make it straightforward to map your model to your database. I wish ardently for Entity Framework to be this kind of ORM.

Thanks for taking the time to voice your criticism. In retrospect, my work with Entity Framework should have been split up into two posts.

1. We’ve made the decision to quote all table and column names in generated SQL in order to support all existing databases with mixed-case column and table names. Unfortunately unquoted identifiers are translated to uppercase by Oracle, which makes dealing with them a bit unpleasant as you have noticed.

2. The recommended way to deal with uppercaseness of Oracle in EFv1 is to use MSL to map nice-looking property names in your conceptual model (CSDL) to all-caps names in storage schema SSDL. We generally don’t envision majority of people working directly on SSDL and re-generating CSDL/MSL every time database changes (which leads to suboptimal class and property names), but that’s definitely a possibility. In this case, you can think of writing a post-processor to CSDL/MSL files which will adjust the casing of properties as required. However, I would recommend maintaining CSDL/MSL by hand and re-generating SSDL from the database.

3. The Namespace attribute of Schema is there just to qualify entity type names. We typically use “ModelName.Store” convention, but “Administration” will also works fine. Fully qualified SSDL type names (”TestAppEFModel.Administration.Assets” in your case) are not used outside of SSDL, but the namespace is used for store-specific functions declared in SSDL, so you may want to keep this simple and readable.

4. Thanks for pointing out the INSTR and ROWNUM issues. I’ll try to fix those issues and post the updated version soon. As stated in the documentation, the provider did not undergo rigorous testing and is there mostly for educational purposes and should not be used in any production environment.

5. Regarding Ruby: In EFv2 we are working on improving our developer experiences by introducing more convention-based mappings and POCO object support. We are always open to suggestions and ideas that might improve the final product. We have recently opened up our design process - feel free to comment on our design blog: http://blogs.msdn.com/efdesign/. Or you can just contact me directly at jaroslaw @dot@ kowalski @at@ microsoft @dot@ com.

Jarek