eXpress Persistent Objects - 2020 Roadmap

XPO Team Blog
22 January 2020

To help us deliver the best possible features for the eXpress Persistent Objects (XPO) ORM library in 2020, please take a moment to review the list below and share your opinions with us.

Housekeeping & .NET Core

There are a number of housekeeping tasks that need to be completed during each release cycle. The following list summarizes our plans for 2020. 

SQL Server "Always Encrypted"

We hope to refactor our core to introduce typed query parameters (for instance, null parameters with type information or additional information such as ping). This will help us support Always Encrypted - a very important feature for enterprise customers. Batch updates and operations on slow connections will also benefit from this refactoring. Expect a Beta in v20.1 and a final release in v20.2. 

Database Schema Migrations

We want a simpler process to incrementally update database schema and preserve existing data after changes are made to XPO’s data model (AS4684). At present, we handle initial database creation and schema tuning along with basic data model changes only (create tables and columns for new classes and properties). For more complex sync tasks, developers need to create database scripts or specialized helper methods. For instance, XAF's ModuleUpdater ships with the DropColumn, RenameTable, DropConstraint and other APIs for Microsoft SQL Server for this purpose. Our goal is to make this process better than that found in EF Core Migrations. Expect a Beta in v20.1 and a final release in v20.2

Your Opinion Counts

As always, we look forward to your comments and questions. Please share your thoughts below or email xpoteam@devexpress.com.

Showcase Your Apps on DevExpresss.com

Highlight your business app and share your development experiences with the DevExpress community. To include your app in our upcoming App Showcase, please forward an application screenshot to clientservices@devexpress.com and tell us which DevExpress products you currently use within your organization.
The information contained within this blog post details our current/projected development plans. Please note that this information is being shared for INFORMATIONAL PURPOSES ONLY and does not represent a binding commitment on the part of Developer Express Inc. This roadmap and the features/products listed within it are subject to change. You should not rely on or use this information to help make a purchase decision about Developer Express Inc products.
19 comment(s)
Niels Elzen
Niels Elzen

Q1

we would deffenetly go for: 

Generate diffs between the latest data model and existing database schema so that you can apply the SQL script manually. 


As in many cases data must be migrated in a specific way. 


9 December 2019
DIP_Michel
DIP_Michel

Q1

I would prefer the diff between the latest data model and an existing DB.

After that it should be possible to migrate data from the old version to the new version via code.

Finally there should be a way to remove old columns, tables, etc.

Don't forget to clean up the XPObjectType Table.


9 December 2019
Daniel Hüttenberger
Daniel Hüttenberger

+1 forQ1

9 December 2019
Mario Blatarić
Mario Blatarić

Hi, 

Q1: I would also go with diffs which we can customise further since there are quite often specific out-of-model updates that needs to be handled manually anyway. 

In XAF, we had to extend all extension methods like DropColumn and others into SafeDropColumn, because default ones would more often fail than work because of complex model with many dependicies, so many additional checks had to be done before dropping column or renaming, for instance. 

Q2: I haven't done any JSON/OData binding, so I can not comment directly, however, I would very much like to see ability to "bind" data-model to web api in as easy and straightforward way as possible. 

My next project will be Blazor based and I will separate data from UI layer which will allow me easy switching between ServerSide Blazor and ClientSide Blazor. 

So, it would be amazing to have an easy way to use web api as datasource for my client model, instead of the database. 

I might be talking stupid here, because I am only yet thinking about this, did not do actual research of what can be done and how. I don't even know if this is possible, if server and client can work together in a way silverlight RIA services worked with same data-model both on server and client - something like that would be REALLY nice for apps I am building.

Or marking certain classes on server as "client" in shared library marked with PersistentUrl attribute which would point to Web API method(s). 

So, I apologise in advance if my Q2 comments make no sense here - Q2 question poked my mind in this direction, perhaps further discussion would be due somewhere else :-) 


9 December 2019
Manuel Grundner [DevExpress MVP]
Manuel Grundner [DevExpress MVP]

Hi Folks!

Q1: I would prefer option 2, but having a cli that compares schema and writes out code/schema changes would be awesome esp when running on the build server. EG: Is a PR introducing a DB change? 

Q2: I have no problems with the JsonSerializer in the demos. Most of the time I need to customize it. But I use a more generalized version that uses TypesInfo and some custom attributes that specify how the serialization should look like (more a DDD approach)

Keep up the great work! 


9 December 2019
renejdm
renejdm

Both schema and data migrations are a huge problem. I am not really sure what you are envisioning as this is a very complex problem. Are you planning on implementing schema migrations only for SQL Server or for all databases that XPO works with? It is conceptually easier to work with SQL scripts so are you planning to only create diff scripts and then it is left up to the developer to manually create a migration/update mechanism?

There are a number of projects that handle both schema and data updates/migrations. "Fluent Migrator" and "DbUp" are two well known free ones. DbUp is very easy conceptually as you would use existing 3rd party tools to create both data and schema diff scripts and then the software will automatically run the correct scripts, and apply them only once, in the correct order.

And being able to do both schema and data updates is very important. They often go hand-in-hand, so your solution should cover both.


9 December 2019
Hedi Guizani
Hedi Guizani

Support for custom sql queries for CRUD and specialy select methods can be a great move for XPO,

https://www.devexpress.com/Support/Center/Question/Details/T743928/custom-sql-in-xaf

It can be extremly usefull in many scenarios, and improve performence in complicated senarios.

This feature already exists in EF and even in regular ado.net APIs why not XPO?

We hope to see this feature in future releases, 

Thansks 


10 December 2019
Peter Annandale
Peter Annandale
Definitely Q1
11 December 2019
Thorsten T
Thorsten T
For sure Q1.
11 December 2019
Chris Royle (LOB)
Chris Royle (LOB)

Q1. We'd prefer a generated script which we can process manually e.g. to add filtered index criteria / change replication configurations. Someone else has touched on generating drop statements for tables/columns/fields/indexes - this would be a handy addition even if this was created within a comment block of the script.

Q2. Not something we're affected by.



12 December 2019
Thomas Keller 4
Thomas Keller 4

Q1: Preferably automatic. I did some work in EF recently and once in a while EF's approach comes in handy, but most of the time it's just unnecessary pain to manually take care of migrations. +1 for XPO's already existing automatism.


Q2: In recent / past projects (Web-API-based) we usually had business logic process data between database and the controllers / api-endpoints, so we did not directly expose persistent objects. However, researching the topic of OData and "direct json exposure" every once in a while, I never really managed to get a good solution working (especially combined with a richclient to send / receive data with little boilerplate and / or LINQ backed client queries).

Upcoming projects are going to involve a combination of Blazor-parts (client and / or server side) and Api-Controllers. So maybe there are some "tricks" to simplify data handling I do not yet know about.

As an idea, I think some scaffolding capabilities would also be helpfull. Similar to what can be done with EF, but with XPO. First thoughts would be CRUD-web-api-controllers and something "CRUD view" for blazor (like a component with a datagrid and editor functionality based on persistent objects).

12 December 2019
Uriah (DevExpress Support)
Uriah (DevExpress Support)
Hi,

@All, thank you for your feedback. The XPO team is very grateful for useful information.

@renejdm, we are considering both solutions - creating a command-line migration tool/ORM Data Model extension, or creating diff scripts. In both cases, the solution should work with all databases supported by XPO.

@Hedi Guizani, do you mean the Raw SQL Queries feature? If so, XPO provides a similar feature: Direct SQL Queries.

13 December 2019
Xian
Xian

Q1. What is the ideal solution for XPO Database Schema Migrations? We are considering the following solutions:

  • Update schema automatically via a special command in the ORM Data Model Designer or some CLI.
    => NOT NEEDED
  • Generate diffs between the latest data model and existing database schema so that you can apply the SQL script manually.
    => THATS THE WAY TO GO!
13 December 2019
Stephen J White
Stephen J White

Q1 Answer:

I could see both scenarios being useful. The way EF Core handles it is pretty flexible right now (creating migration scripts via CLI/Package Manager and then being able to modify them further by using SQL Scripts or adding additional steps to handle data cleanup or other tasks). I'd prefer it if you could consider honing on this flexibility in the future, as it is one of the reasons why I continue to use EF despite the fact that I have wanted to use XPO. 


14 December 2019
Turki Alanazi
Turki Alanazi

Dennis, I’m happy to see XPO Database Schema Migration on the roadmap this year for sure it is the most important feature for me. I have requested this the last year. However, it wasn’t implemented. I would love to see both options:

1- Updating schema automatically via a special command in the ORM Data Model Designer or some CLI.

2- Generating diffs between the latest data model and existing database schema so that you can apply the SQL script manually.

 I think once 1 or 2 has been implemented the other part would be easy to implement, but if I have to choose I would choose updating schema automatically via a special command in the ORM Data Model Designer. I would like to be able to reflect changes on my model from the designer on the database and vice versa.

It would fantastic if there is an option that would allow me to update the model in the background automatically once a change happens to the database structure without special commands or CLI and vice versa.

Another idea that could be implemented is the ability to take snapshot of the model and restore it at any time without creating backup copy from the model before making changes to it. A window within visual studio will be there so I can choose which snapshot of the model I want to restore.

Finally, I wish you good luck implementing the suggested feature & I’m looking forward to use them.

 
24 December 2019
Uriah (DevExpress Support)
Uriah (DevExpress Support)

Thank you, Turki!

Another idea that could be implemented is the ability to take snapshot of the model and restore it at any time without creating backup copy from the model before making changes to it. A window within visual studio will be there so I can choose which snapshot of the model I want to restore.

Version control systems already address requirements like that. You can reset all changes if something goes wrong or experiment with different versions at the same time. Please refer to the following blogs as an example: A Git workflow for code experiments, Doing Quick Experiments In Git.

27 December 2019
Robert McNeal
Robert McNeal

I know I'm a little late to the game, but I agree with most that the generated scripts is the way to go.

Also, I'm wondering if there would be a mechanism for both UPgrade and DOWNgrade of the schema or will it be a one way street?

16 January 2020
Dennis (DevExpress)
Dennis (DevExpress)
@Robert McNeal: For now, we have thought only about the upgrade. Would you please describe your downgrade use-case scenarios and their frequency/importance in the last 1-2 years? Thank you.

22 January 2020
Martin Pelletier
Martin Pelletier

Hello,


I know you have a sample about XPO and WPF MVVM. Not easy to follow for me any way. But I would like a nice step by step example in the documentation on how to use XPO with WPF MVVM. Kinda like the Scaffolding examples. Easy to follow and I was able to understand how things work I was able to learn fast. 

23 January 2020

Please login or register to post comments.