Blogs

XPO

eXpress Persistent Objects

XPO–11.2 Sneak Peek - Auto-generated Int64 keys

We are not far from 11.1 and I presume that you will be surprised to see 11.2 sneak peeks at this timeSmile

There is not actually not much to say here, because the subject says it all. Starting from version 11.2 you can define a Int64 (long) key property in your class and mark it with the KeyAttribute, whose AutoGenerate parameter will be set to True:

  1: [NonPersistent, MemberDesignTimeVisibility(false)]
  2: public abstract class XPObjectWithInt64Key : XPCustomObject {
  3:     ...
  4:     Int64 _oid = -1;
  5:     [Persistent("OID"), Key(AutoGenerate = true)]
  6:     public Int64 Oid {
  7:         get { return _oid; }
  8:         set {
  9:             Int64 oldValue = Oid;
 10:             if (oldValue == value) return;
 11:             _oid = value;
 12:             OnChanged("Oid", oldValue, value);
 13:         }
 14:     }
 15:     ...
 16: }
 17: public class TestPerson : XPObjectWithInt64Key {
 18:     public TestPerson(Session session)
 19:         : base(session) { }
 20:     private string firstName;
 21:     public string FirstName {
 22:         get { return firstName; }
 23:         set { SetPropertyValue("FirstName", ref firstName, value); }
 24:     }
 25:     private string lastName;
 26:     public string LastName {
 27:         get { return lastName; }
 28:         set { SetPropertyValue("LastName", ref lastName, value); }
 29:     }
 30: }

Interested readers will notice that for my base persistent class I grabbed the source code from the standard XPObject class and then just changed its key type from Int32 to Int64.

Well, if you now create and save a new object, a key will be automatically generated for it:

screenshot

I hope you like this small addition to XPO, because it provides you with more flexibility (previously auto generation was supported only for Int32 and Guid keys).

Please let us know your thoughts on this.

Happy XPOingWinking smile

Published Jul 28 2011, 08:30 AM by
Filed under: , , , , , ,
Bookmark and Share

Comments

Mark Krasnohorsky

Excellent! It is about time. I can finally take out some of those hacks I have in place due to this current limitation.

July 28, 2011 12:54 PM

Robert Kapuściński

nice work. We need this

July 28, 2011 2:10 PM

Johnny K

we would like to use and vb.net samples plz!

also are int32 allready run out? and int64 is so important?

i dont know, maybe because my records are not in the billions....

July 28, 2011 5:50 PM

Marc Greiner (DevExpress MVP)

@Johnny

By default, XPO uses an « int » for the object key.

The C# « int » is what got called « Long » in VB.

If you use such a type as a key for your objects, you can have up to 2 billion records in a table. This is quite a lot, enough for most uses.

Some XPO users asked for bigint keys (64 bits), simply because they have object lists with more than 2 billion records and they don't want to use GUIDs, which is very understandable (GUIDs have several drawbacks).

July 28, 2011 6:49 PM

James Zhong

Good!

July 28, 2011 8:49 PM

Arjan van Dijk

For some scenarios it could be usefull especially if you've billions of records like in telecom. Also, in legacy sql databases there are sometimes identity-gaps so the identy values jumping to very big numbers. In these cases (maybe you must get rid of those "gaps" first) the bigints are a (temporary?) solution.

July 29, 2011 3:30 AM

Przemyslaw Wlodarczak

Finally

July 29, 2011 5:00 AM

Felipe R Machado

I was one of those developers that cried out and loud for this. Our application works with auto-increment fields gathering hundreds of thousands of records each day and we needed a clustered index on the Oid because we needed to get to it as fast as possible given the ID. That was unfeasible using GUIDS because a clustered index in a GUID column will rebuild the index pages all the time since the new record can't be appended at the end because GUIDS are inherently not sortable (which is very stupid, if they'd put the time information at the beginning it would probably work for most situations...). An int32 key field wouldn't work too, because 2 billion records is not enough to cope with all the data through the lifetime of the project...

That's why this simple change is enough to warrant an upgrade!

August 1, 2011 12:37 PM

Dennis (DevExpress Support)

@Felipe and others, we are happy to hear that you liked this feature!

August 3, 2011 9:40 AM

Sebastian Kiš2

This is great!

Only one more thing is missing in XPO -> using NUMERIC instead of money for decimal (SQL Server)

I often have values that are more precise than 4 decimal places (like 6 or even 9 decimals) and then manually hack data layer to fit it into money :(

August 13, 2011 2:14 AM

CassanGerard

I agree for an int64 OID.

in persistent Data tables , when objects are inceasedly created and deleted, OID grows . What happens when the max value is attained ?

So, yes for an int64 auto-incremented index

August 14, 2011 5:42 PM

Manfred Waldmeyer

@Dennis:

How can int64 OID from different source databases be merged?

Our mobile/stationary CRM Solution "oPenCRM 2011", that we are working on, uses offline SQLite DBs on  mobile devices (up to 250 tablet PCs e.g.) and MS SQL Server on stationary PC workstations.

The users can create new records and records referencing these records (eg. order header - details) on their mobile devices and sync their mobile db with the server db. Stationary users can do the same on the server based data.

We currently use guids despite the known indexing problems. Therefore it would be nice if the the autogenerate process would allow using a set of distinct mask MSBs for each database.These bits are ored in the upper part of the OIDs and the incremental bits in the LSB part.

Would that be a possible feature?

August 15, 2011 12:02 PM

Arnold King

Thanks! It's needed!

September 15, 2011 1:32 PM

A486889

I am afraid the Auto-generated Int64 keys do not work with PostgreSQL (we are using the Ngpgsql ODBC provider v2.0.11.92 + PostgreSQL 9.1.2).

The table column for the auto-generated primary key of type int64 in the base class is incorrectly generated as integer, although in all inherited classes the table column for this field is correctly generated as bigint.

Nevertheless, even though the above sample does not work with PostgreSQL I must point out that the auto-generated primary key of type int64 is correctly generated as bigint in Microsoft SQL Server as advertised (i.e. the above sample code works flawlessly with MS SQL, just not with PostgreSQL).

December 18, 2011 2:27 PM

ari laksono

good, its time to big data...

good bless DXv2

December 28, 2011 12:30 AM
LIVE CHAT

Chat is one of the many ways you can contact members of the DevExpress Team.
We are available Monday-Friday between 7:30am and 4:30pm Pacific Time.

If you need additional product information, write to us at info@devexpress.com or call us at +1 (818) 844-3383

FOLLOW US

DevExpress engineers feature-complete Presentation Controls, IDE Productivity Tools, Business Application Frameworks, and Reporting Systems for Visual Studio, along with high-performance HTML JS Mobile Frameworks for developers targeting iOS, Android and Windows Phone. Whether using WPF, Silverlight, ASP.NET, WinForms, HTML5 or Windows 8, DevExpress tools help you build and deliver your best in the shortest time possible.

Copyright © 1998-2014 Developer Express Inc.
All trademarks or registered trademarks are property of their respective owners