Thanks to great user feedback, we had a successful release with several major new features. In this post, I will highlight a number of smaller, but useful additions to our ORM and its associated learning materials.
MySQL 8.0, PostgreSQL 11 and IBM DB2 for .NET Core Support
XPO v18.2.3 supports MySQL 8.0 and PostgreSQL 11 database engines. In several weeks, XPO v18.2.4 will also support the IBM DB2 provider for .NET Core / .NET Standard 2.0.
Custom GUID Generation
Requested by several users who experienced better INSERT performance on large databases with CombGuid (T607385). You can now provide a custom Guid primary key generation algorithm globally as described in this example.
XPObjectSource Tutorials & API Reference
As you may remember from our previous post, XPObjectSource is a new first-class citizen in DevExpress Reporting and is used to reduce the amount of code needed to bind reports using XPO data. To learn more about this new capability, refer to the following documents: Tutorials | API Reference.
And, please take our one-minute survey and share your opinion about XPObjectSource and other new reporting data source types.
WCF Data Services 5.7 support
The DevExpress.Xpo.Extensions library that provides XPO data service for OData V3 now supports WCF Data Services 5.7. You no longer need assembly binding redirections to target the latest version of a Microsoft package.
If you missed our previous post, there is now a better way to create interoperable data services - with XPO, Web API and OData v4.
Async/Await Methods Documentation
The async/await language feature is a de-facto standard and its concepts are well described in the Microsoft .NET Guide: Asynchronous Programming Patterns | Task-based Asynchronous Pattern.
Question 1: Do you require any additional concepts in XPO documentation besides a formal API Reference like Session, XPQueryExtensions? Are our existing examples, blog posts, online and offline demos and KB sufficient?
Where are simplified SetPropertyValue, GetCollection and other APIs?
As you may recall from our previous posts (one, two), we hoped to simplify SetPropertyValue, GetPropertyValue, GetList, and GetCollection methods and avoid passing a property name as a string parameter. Very promising .NET's Caller Information feature did not help us due to a VB.NET limitation (broken overloaded method compilation with the ref keyword).
Instead, we thought about updating our demos and documentation to use the nameof keyword. We consider this important for new and existing clients who might derive implementation ideas from our learning materials and experience problems later (for instance, property renaming is more difficult with hardcoded strings).
Question 2: Do you feel its important that we update our learning materials or do you not see any issues and nameof with or without CodeRush templates is already sufficient?