in
Forums
Blogs
Files
Devexpress.Com
ClientCenter
DevExpress Channel

XPO

eXpress Persistent Objects

March 2007 - Posts

  • ANN: DXCore XPO plugin 1.1.0.2

    Here it is, another updated version of the XPO plugin. For some news that still apply to this update, please see my recent post. If you have no idea what this XPO plugin thing is about, you might also find this description of the "Simplified Criteria Syntax" feature useful.

    Here's the download for the newest version: CR_XPOFieldSync-1.1.0.2.zip (19764 bytes)

    Note: please make sure that this is the only version of the plugin you are using! I’ve seen a case in the past where there was more than one version of the plugin installed (several copies of the assembly in the plugin folder, with different names), and of course this results in some weird problems…

    News

    Here are the fixes in this version:

    • Fixed CB36365 - generic base classes are now handled correctly.
    • Fixed a problem where the base class of the FieldsClass wasn't changed correctly after the base class of the persistent class had been changed.
    • Implemented CS30989, in part. The important thing is that classes which derive from persistent classes will now get the strucures created even if they have the NonPersistent attribute applied, unless they are sealed.
    • The DefaultMembersPersistenceAttribute is now handled correctly.
    • The namespace DevExpress.Xpo.Helpers is now included in the file, in case the FieldsBaseClass is used as a FieldsClass ancestor.

    Outstanding issues

    • CB8627 – this bug is about the problem of incomplete structures. As I have previously reported in the issue comments, this is a problem without an easy solution at the current time, as the DXCore parser isn’t able to deliver the information I need. I have tried some workarounds, but without success so far – a complete solution of the issue may only come along with the introduction of a new parser in DXCore.

    Status

    Apart from the big known issue documented in CB8627, stability is pretty good as far as I know. Please let me know, preferably by way of the support center, of any issues you find.

  • New version of the DXCore XPO plugin - help me test!

    I've prepared a new version of the XPO plugin for DXCore. For those of you who haven’t used that plugin before – here’s the introduction of the “Simplified Criteria Syntax” feature. Once the new plugin version has been tested, I’ll have to make some changes to that page…

    Here’s the download of the new plugin version: CR_XPOFieldSync-1.1.0.1.zip (18330 bytes)

    Note: please make sure that this is the only version of the plugin you are using! I’ve seen a case in the past where there was more than one version of the plugin installed (several copies of the assembly in the plugin folder, with different names), and of course this results in some weird problems…

    News

    So what’s new in the new version? A whole bunch of things. See here, and read carefully:

    It is compiled for .NET 2. It will not run with .NET 1.x.
    Of course this means it can only be used in Visual Studio 2005.

    It creates code that is only compatible with XPO version 7.1 and later.
    The 7.1 RC that is currently available can be used with this plugin version, but no version earlier than that. My plan is to “backport” some of the bug fixes to a version of the plugin that will be the final version made available for .NET 1.1 compatibility (XPO 6.3 and older).

    It is compiled for DXCore 2.1.3.
    In my experience, compatibility with newer DXCore versions should be very good (although we’ve seen breaking changes in the past, if rarely), older versions will not work.

    There’s rudimentary logging support
    The plugin can log some information to the CodeRush Messages window. This can be helpful to track down bugs. The Messages window can be accessed from Visual Studio via the menu – DevExpress | Tool Windows | Diagnostics | Messages.
    The plugin has a new option “Logging active” that enables logging, it’s disabled by default.

    The structure of generated code has changed
    I have changed the structure of the code that the plugin generates. The reason for this is a suggestion submitted by a customer (thanks!), and the new structure allows using “long”, i.e. concatenated property names in queries (OrderLine.Fields.Order.Customer.CompanyName == “Developer Express”).
    The plugin has been changed to remove any old-format Fields class automatically and create the new structure instead.

    “new” and “Shadows” are now applied correctly (AB7485)

    “Persistent”, “NonPersistent” and “PersistentAlias” are interpreted correctly (CB18441)

    Outstanding issues

    Apart from ideas I have – of which there are quite a few –, there are also issues that are currently active in our support center, but haven’t been addressed in this release. I want to mention two such issues here:

    CS30989 – this is about the complex situation where classes in a hierarchy are partly persistent, partly non-persistent. It will require some thought to come up with a good implementation of this.

    CB8627 – this bug is about the problem of incomplete structures. As I have previously reported in the issue comments, this is a problem without an easy solution at the current time, as the DXCore parser isn’t able to deliver the information I need. I have some ideas for workarounds in this area and I’ll try to implement them – a complete solution of the issue may only come along with the introduction of a new parser in DXCore.

    Status

    I have done a lot of tests on this version, both in C# and VB.NET, but I’m absolutely sure there are more bugs in there that can be found. I’m planning to quickly fix any problems that are reported in the near future, and release another updated version soon. Of course this will work only if at least some of you download the current version and test it :-) I’d appreciate it if you did that and helped me with your bug reports – preferably please enter them in Support Center, so I can easily track them.

  • XPO 7.1 RTM - news about delayed properties, and a (potentially) breaking change

    Before you panic: this change is unlikely to actually break anything for the large majority of XPO users. Let me describe.

    Following a suggestion from a user, we implemented support for delayed properties in our simplified property syntax scheme. Looks like this:

      
      [Delayed]
      public Byte[] BigPicture {
        get { return GetDelayedPropertyValue<Byte[]>("BigPicture"); }
        set { SetDelayedPropertyValue<Byte[]>("BigPicture", value); }
      }
    

    As you can see, there’s no explicit storage variable used in this example. This is basically case (2) from my description of the variations of simplified property implementation. For delayed property implementation this is the recommended syntax from XPO 7.1 onwards – the one disadvantage outlined for case (2) was the absence of the local storage field. This is not a disadvantage for delayed properties, as the storage field itself (the one of type XPDelayedProperty) wasn’t any use for the programmer anyway.

    So what’s that about a breaking change?

    There are two important details that may change your application’s behaviour to some degree:

    1. Setting the delayed property value now fires an OnChanged event – a good thing, but a change nevertheless.
    2. For the change notification, the old value of the delayed property will be fetched from the database if it hadn’t been fetched previously.

    Note: This change is only in the final 7.1 version of XPO, not in the RC that is currently available.

Copyright © 1998-2008 Developer Express Inc.
ALL RIGHTS RESERVED