Current filter:
                                You should refresh the page.
                                  • UPDATED by Dennis (DevExpress Support):
                                    From the DevExpress ORM Tool > Fundamentals > When and Why XPO Extends the Database Schema article:
                                    "Note that while XPO can create database schema objects, it cannot modify them later.
                                    XPO cannot modify properties of tables, columns, indices, or foreign keys created according to persistent class definitions. In particular, XPO does not change the size and underlying type if the settings specified via the SizeAttribute and DbTypeAttribute attributes are changed. Also, XPO does not remove unused columns and tables if a persistent property or class was removed. Class/member renaming is not tracked and is treated as one class/member is deleted and a new one is added. Renaming a persistent class mapped to an existing database table is a serious change that requires adjusting the database structure and most likely data as well, according to the new class name. If you do not have any sensible data in the database yet, then the easiest solution is to drop your database and let XPO recreate it from scratch. Otherwise, you will have to manually modify your database structure or use SQL scripts to modify it according to the new data model structure. If you want to rename a class or a field in code only, and leave the mapped table or column name unchanged, you can use the PersistentAttribute with the PersistentAttribute.MapTo parameter to specify mapping to an existing table or column."

                                Show all comments
                                • Chris W. 02.22.2013

                                  Wow, 7 years...are we any further on this?

                                  I would greatly appreciate being able to alter the size in code and when redistributed to customers we don't have to write update scripts for all DBs you support in XPO.

                                • Michael (DevExpress Support) 02.22.2013

                                  Thank you for your interest in this functionality. We cannot provide any estimate on when it will be implemented.

                                • Francois Nel 02.22.2013

                                  Yip, have been monitoring this item for many years. We have decided to go with EF in our new projects and this feature being one of them. Luckily we only had to deal with MS SQL in our old projects, so it was only one DB platform to write scripts for... but not in the new ones...

                                • Hans Merkl BSC 04.03.2013

                                  I think DevExpress is thinking too big here and there fore doesn't implement it. Being able to change the length of a field or deleting a filed would go a long way,

                                • Bernie Bialt 1 04.03.2013

                                  As you can see from the other comments and requests left on this topic, that you are preaching to the choir. The only thing I can surmise is that it is too difficult to keep the model and schema in sync.

                                • Hans Merkl BSC 04.03.2013

                                  "a steady drip of water will split stone ". I just want to keep the topic alive :-)

                                • Trevor Westerdahl 04.03.2013

                                  This shouldn't be about model and schema as much as its about making changes. Someone suggested this:
                                  "I just include this in my DBUpdater using ((XPObjectSpace)ObjectSpace).Session.ExecuteNonQuery(). Personally I no longer have a need for this, and I assume this is what DX wants you to do as well."
                                  That, of course, completely ignores the "in a DB independent way" which was core to my point. There are simply certain properties that might need to be adjusted after the schema was auto-generated. I won't mention names but other ORM products do correct properties in an object-oriented, DB-Independent way.
                                  It would simply add great value to me to have this. I can and do use all sorts of techniques to correct schema. A database independent set of tools to go hand-in-hand with XPO would be awesome!

                                • Hans Merkl BSC 04.03.2013

                                  Completely agree with Trevor. and I don't believe it would that hard to implement if kept at a limited scope.

                                • Robert Fuchs 04.03.2013

                                  +1 for Trevor.
                                  And BTW, guys, why don't you vote this suggestion up?!
                                  Only 2 upvotes, and one is by me...

                                • Ralph Rutschmann 04.03.2013

                                  +1 from me!

                                • Norbert Kustra 04.03.2013

                                  +1 for Trevor

                                • Horst Molderings 04.04.2013

                                  +1 for Trevor

                                • Francois Nel 04.04.2013

                                  You see Robert, this suggestion was logged 7 years ago (and yes, somehow I'm still following this post). Back then there was no "up vote" on question/suggestions
                                  An this is one of the reasons we went with "I won't mention names" ORM :-P

                                • wolfgang hauer 04.04.2013

                                  +1.

                                • drew.. 04.04.2013

                                  Absolutely.. there are a basic subset of changes that every single developer dealing with real-world clients face: removal of fields, field name changes, field size changes and the most time consuming change: relationship changes. EVERY SINGLE PROJECT encounters this. EVERY TIME.
                                  Scope it to the first three and most of us would be happier. Add the forth and i would be very happy.

                                • Trevor Westerdahl 04.04.2013

                                  The irony is that I am having to update schema for XPO at this exact moment. Seven years later and I still could use it on a regular basis. What is needed seems to scream for the use of polymorphism and the use of an interface.
                                  For example,
                                      public interface IXpoSchema {
                                          /// <summary>
                                          /// Renames the underlying database field.
                                          /// </summary>
                                          /// <param name="classInfo">The express persistent object class info.</param>
                                          /// <param name="originalName">The original filed name.</param>
                                          /// <param name="newName">The new field name.</param>
                                          void RenameField(XPClassInfo classInfo, string originalName, string newName);
                                          /// <summary>
                                          /// Changes the size of the string-based field in the underlying database.
                                          /// </summary>
                                          /// <param name="classInfo">The express persistent object class info.</param>
                                          /// <param name="fieldName">The field name.</param>
                                          /// <param name="newSize">The new size.</param>
                                          void ChangeStringFieldSize(XPClassInfo classInfo, string fieldName, int newSize);
                                          /// <summary>
                                          /// Changes the name of the index within the underlying database.
                                          /// </summary>
                                          /// <param name="classInfo">The express persistent object class info.</param>
                                          /// <param name="originalName">The original index name.</param>
                                          /// <param name="newName">The new index name.</param>
                                          void ChangeIndexName(XPClassInfo classInfo, string originalName, string newName);
                                          ///yada yada, keep adding support for more changes
                                      }
                                  I'm not saying this idea I just made up of the top of my head is "the answer", but at first glance, it seems an interface similar to above could be created and then implemented in classes for each database type supported by XPO. A factory pattern would determine which class/instance to instantiate based on the Session supplied to the factory.
                                  With something like that in place, I could change a field name in a database-independent way. Every additional method added would expand the options available.
                                  Seriously, who uses XPO and does not want this? What value would it add to XPO? How hard would it be, really, to start implementing features similar to those suggested?

                                • Hans Merkl BSC 04.04.2013

                                  I think Drew's first three changes (field removal, field size change and field name change) would be relatively straightforward. I have several projects where I had to do all of these and it was pretty simple but it got tedious when I had to make them work for different databases. I would like to add change of default value to this list.
                                  I can see how changing relationships automatically would be complex so I don't it would be a good idea tackling it right now.

                                • Systellence 04.10.2013

                                  Hi DevExpress
                                  Really, this is needed and will truly add value to XPO. I am also now stuck with a problem where I need this. Using XPO for more than two years.......
                                  It is a pity that this has not been implemented already long ago.
                                  Surely an ORM should include this.

                                • Apostolis Bekiaris (DevExpress) 04.14.2013

                                  In eXpand core modules the XpandObjectSpaceProvider has a similar functionality
                                  https://github.com/expand/eXpand/commits/master/Xpand/Xpand.Xpo/DB/SchemaColumnSizeUpdater.cs
                                  This updater is register from this proxy
                                  https://github.com/expand/eXpand/blob/master/Xpand/Xpand.Xpo/DB/DataStoreProxy.cs

                                • Trevor Westerdahl 04.15.2013

                                  From what I understand, eXpand is a set of 3rd party functionality designed specifically for Express App (see point 2 below).

                                  1. My request is specifically related to XPO, not eXpress App
                                  2. I want an officially-supported solution. I can and do port/write/create my own solutions. This functionality is so widespread and commonly required, it should be implemented in the base product: XPO.
                                  I am disappointed that you reference a 3rd-party product and am even more disappointed that you don't see the value having this functionality added to XPO. Virtually 100% of all long-term users would want this.
                                • Hans Merkl BSC 04.15.2013

                                  Agree with Trevor 100%

                                • Oliver Avieny 04.15.2013

                                  +1
                                  If you can just start with, length of a text field.

                                • Gerry Knight 04.15.2013

                                  +1
                                  If you can just start with, length of a text field.
                                  I agree.
                                  Lots of people seem to have been following this thread for years :) that's got to mean something.

                                • Apostolis Bekiaris (DevExpress) 04.15.2013

                                  @Trevor I agree with you that this is a really wanted functionality I only reference a n open source solution here in case anyone wants to see how it is implemented. The suggestion is open and our guys monitor and will act if there are many requests.

                                • Jascha 04.16.2013

                                  Let me add a "vote" to the addition of the feature to extend text field length - that is a fairly risk-free and simple addition that would avoid runtime sql truncation errors.

                                • Robert Fuchs 04.16.2013

                                  Like some others suggested, in addition to field size change (maybe only allow to enlarge size but not shrink), also field name change and field removal would possibly be straightforward to implement.

                                • Norbert Kustra 04.16.2013

                                  Agree with Jascha and Robert

                                • Matteo Lazzari 07.12.2013

                                  +1
                                  It would be a very useful feature.

                                • Anderson Luiz Mendes Matos 08.08.2013

                                  Wow. 8 years.
                                  I think that this will be a major no-go for me.
                                  Sadly, I'll have to reconsider moving from EF to XPO.
                                  Can't afford to go back into SQL-based commands for database migration.
                                  =/
                                  Has my upvote at least. Hope this will come soon enough.

                                • Hans Merkl BSC 08.08.2013

                                  Anderson Mendes Matos,
                                  I am curious, is EF better in that aspect?

                                • Holger Persch [DX-Squad] 08.08.2013

                                  EF has it's Code First Migrations that gives you all functionality to migrate databases up and down.

                                • Anderson Luiz Mendes Matos 08.09.2013

                                  Yeah. EF Migrations make it easy to update/downgrade database schema based on classes.
                                  Also, it enables me to seed and update seed data for every migration.
                                  EF has it's own cons too, that's why I was plannig to use XPO.
                                  An interesting idea that came during the night was to use both.
                                  EF just to update the schema (EF Migrations).
                                  XPO for everything else.
                                  This should be interesting.

                                • Hans Merkl BSC 08.09.2013

                                  That's good to know. I looked at EF while ago and found it a little over-engineered in typical Microsoft fashion. At that time they didn't have schema updates so went with XPO. Maybe it's to revisit that decision. It seems Developer Express is not doing much development for XPO anyway.

                                • Robert Fuchs 08.12.2013

                                  @Anderson Mendes Matos:
                                  > EF has it's own cons too, that's why I was plannig to use XPO.
                                  What are the cons? (I only use XPO currently.)
                                  > An interesting idea that came during the night was to use both.
                                  You would need to keep 2 models synchronized then - how would you do that?

                                • Anderson Luiz Mendes Matos 08.13.2013

                                  @Robert Fuchs (and others)

                                  1. EF Pros and cons
                                  --------------------
                                  Pros and cons may vary from one goal to another (and from one project to another). Please, don't take my answer as an universal truth.
                                  For my meeds, the major cons are EF's poor performance (specially on a winforms crm/erp startup) caused by slow view generation process and provider only for SQL Server (others are paid and may require some special configs).
                                  For my case (erp/crm software) the app startup takes about 25 to 50 seconds MORE just because of EF. Total startup time is around 60 seconds. This is a pain for winforms app. And any improvement sticks around 1 or 2 seconds only.
                                  2. Model sync (EF and XPO working together)
                                  ------------------------------------------------
                                  I'm using EF Code First, which is based on POCO (plain classes).
                                  I'd do the same with XPO.
                                  You should have a single place (folder or project) for business classes which would be shared to both XPO and EF.
                                  By updating business classes (and creating a migration for EF), both would be up-to-date with no other effort.
                                  The point here would be to use the better from each.
                                  Since the update process is already slow and won't run everytime, you can check for model changes manually (both EF and XPO offer you methods to do that before anything else from what I know) and if needed, call EF (which updates model automatically) and dispose it. Than switch back to XPO for regular use.
                                  Both EF and XPO could implement some sort of GenericRepository Pattern.
                                  Doing so you can test/change from EF to XPO and back anytime you need.
                                  This would be my approach.
                                  3. Manual update (simulate EF migrations)
                                  ---------------------------------------------
                                  One thing that I've done before was to simulate EF migration (when it was in alpha) by creating a helper class that could translate a command like AlterColumn("old", "new") into a corresponding SQL/DML syntax.
                                  Since I was using SQL Server this was really easy.
                                  You can always do that too.
                                  Create some sort of translation engine which could recognize the active database (SQL Server, MySQL, etc) and translate the function into a corresponding SQL/DML.
                                  It's what EF Migration does, but for SQL Server.
                                  DX should follow this path too, it's the most logical one.
                                  The point here is to detect the current schema version and to which you should update. Perform the update and update a control table which tells you the current schema version.
                                  Just remember to provide a downgrade path too.
                                • Hans Merkl BSC 08.13.2013

                                  I haven't been up to date with XPO for a while. Is there a way to use POCO classes with now?

                                • Anderson Luiz Mendes Matos 08.13.2013

                                  Yeah, sure! Take a look at the "Code-First" section for each topic on the docs: http://documentation.devexpress.com/#XPO/CustomDocument2256
                                  Also, this tells you more about which class to inherit for XPO to understand business classes:
                                  http://documentation.devexpress.com/#XPO/CustomDocument3311

                                • David Perfors 08.13.2013

                                  @Hans, POCO classes are not really supported, you should always use some kind of inheritance. Apparently it should be possible to use POCO classes, but I have never seen any examples of it.

                                • Alexander Monz 11.15.2015

                                  Are there any news regarding the ability to modify the existing database structure in the DB-independant way?

                                • Matthieu Penant 05.26.2017

                                  +1 atm we plan to use an sql project separately to manage the database updates.

                                • Dave McRae 02.20.2018

                                  +1. Well this has been going for a while. I'm assuming there has been no steps forward?

                                • Boom 03.29.2018

                                  Been playing around with XPO and I have to say this feature would convert me over to it from Entity Framework.

                                0 Solutions

                                Creation Date Importance Sort by