Order or DbLinq properties in code generated by pgsqlmetal

[Andrus]

I noticed that order of properties in generated dbLinQ entity classes is
random:
When I bound DbLinq object to DataGridView DataSource, I got messed column
order table.

(When I bound dataset created from SELECT * command to DataGridView, I get
expected order of columns).

Probably column order in changed during generation process, no idea why.

Questions:

1. Is it possible that in generated code property order is the same as
columns
appear in SELECT * and CREATE TABLE commands ?

2. If I extend pgsqlmetal generated class with custom property "a_a" (see
code below), it appears as first property in table . Is it possible to force
it to appear as last property in table ?

Andrus.

[Table(Name = "Klient")]
public class Klient : Eetasoft.Eeva.Entity.Klient {

public Klient() : base() { }

public Klient(System.String a_a, System.String p_kood, System.String regnr )
:
base(p_kood, regnr) {

this._a_a = a_a;
}

protected string _a_a;

[Column(Name = "a_a", DbType = "character")]
public string A_a {
get { return _a_a; }
set { _a_a = value; _isModified_ = true; }
}
}

 

[Marc Gravell]

If you need specific property ordering from generated code (and
assuming you don't want to be editing the code in the generated
"Klient.cs"), this is something that the type-descriptor /might/ be
able to do. Simply re-order the properties from the
PropertyDescriptorCollection that GetProperties() returns. This could
be done either by implementing ICustomTypeDescriptor (from Klient or a
base), or using a TypeDescriptionProvider (and associating it with
Klient or a base) - and calling Sort() on the original collection you
were given (base etc), specifying the desired order:

return props.Sort("First", "Second", "Third");

The problem, though, will be "where to store the desired order?". I
don't have a great answer for that...

If you aren't familiar with ICustomTypeDescriptor or
TypeDescriptionProvider then let me know, but I'm pretty sure I've
covered the basics in another chain with yourself (in the context of
adding dynamic properties).

There may be other ways of doing the same ;-p

Marc

 

[Marc Gravell]

Of course, the other (simpler?) approach is to add the columns to your
dgv in the desired order... ;-p

 

[Andrus]

Of course, the other (simpler?) approach is to add the columns to your

dgv in the desired order... ;-p

I'm curious why pgsqlmetal changes property order.
All other ORM mappers I have seen save the database column order in entity
properties.

Andrus.

 

[Marc Gravell]

Since that is an open-source project, maybe that is a question for the
pgsqlmetal people? I'm just saying you might get a better answer from
a more on-topic forum.

Marc

 

[Jon Skeet [C# MVP]]

Since that is an open-source project, maybe that is a question for the
pgsqlmetal people? I'm just saying you might get a better answer from
a more on-topic forum.

Or indeed, since it's open source, why not have a look at the source
and see what it's doing?

Jon

 

[Frans Bouma [C# MVP]]

I'm curious why pgsqlmetal changes property order.
All other ORM mappers I have seen save the database column order in
entity properties.

To give them credit: there's no 'order' in properties. If you want
them to have an order, sort them.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Andrus]

To give them credit: there's no 'order' in properties. If you want

them to have an order, sort them.

There is order of columns in CREATE TABLE command.
In all databases, SELECT * returns columns in same order as they appear in
CREATE TABLE command.
Postgres bulk load (COPY FROM) command assumes this column order.

 

[Andrus]

Or indeed, since it's open source, why not have a look at the source

and see what it's doing?

Jon,

I looked into source code but havent found any place for ordering.
sql statement which retrieves properties seems to return them in native (as
in SELECT * ) order.
Something in code generation process corrupts ordering but I havent traced
to this place of code, this is a lot of unexplored code to trace.

Before researching this problem more I desided to ask about this, will MS
sqlmetal also place properties to random order or does it preserve SELECT *
order ?
I have used SELECT * commands for many years for my tables and like to
see corresponding entity properties in SELECT * order.

Andrus.

 

[Jon Skeet [C# MVP]]

I looked into source code but havent found any place for ordering.
sql statement which retrieves properties seems to return them in native (as
in SELECT * ) order.
Something in code generation process corrupts ordering but I havent traced
to this place of code, this is a lot of unexplored code to trace.

Before researching this problem more I desided to ask about this, will MS
sqlmetal also place properties to random order or does it preserve SELECT *
order ?
I have used SELECT * commands for many years for my tables and like to
see corresponding entity properties in SELECT * order.

Well, I wouldn't *rely* on ordering of either SELECT * or indeed of
property declarations. It's a bit like relying on hashcode algorithms
staying the same between versions - it may well work for a while, but
it's fundamentally a bad idea.

If you want a particular order, *specify* that order.

Jon

 

[Marc Gravell]

will MS sqlmetal also place properties to random order
I haven't checked; a cursory glance at some code indicates that they
/appear/ to be in the original order; this isn't a guarantee,
obviously. I know that it does specify the original ordinal via
DataMemberAttribute, i.e. [DataMember(Order=9)], but from what I've
seen tracing LINQ-to-SQL from end-to-end, I believe it always requests
things by name, and then (when reading) refers to database fields
using the ordinal from the request it generated, not the ordinal from
the underlying table.

SELECT *

IMO you've done well to have not been burned, then... as always,
different setups will get away with different usage - but I don't
believe that "SELECT *" is a recommended best-practice for production
code. YMMV.

Something in code generation process corrupts ordering

In general, I don't really mentally even /consider/ the physical
(code) order of type-members within managed code. Many class-designers
don't respect it anyway, using primarily alphabetic sort (OK, I'm
thinking MS class diagram here). Nor, indeed, database; if ask for it
by name, so it doesn't matter where it is.

Marc

 

[Nicholas Paldino [.NET/C# MVP]]

Technically, you could rely on the ordering of fields returned with a *
in a SQL query. The SQL-92 specification specifically states that using a *
will return the attributes (columns) in the order that they are arranged in
the table.

It's not best practice, but it can be relied upon.

However, I agree that I wouldn't rely on property ordering in a class in
..NET. I would use a custom type descriptor in this case.

My guess is that the pgsqlmetal tool gets the columns from the table,
and then just declares the properties in the class.

However, when binding that class to a grid, the order in which they are
presented is in whatever way that reflection serves them up.

Which means that the OP should have some specific order specified in
code, IMO.

 

[Frans Bouma [C# MVP]]

There is order of columns in CREATE TABLE command.
In all databases, SELECT * returns columns in same order as they
appear in CREATE TABLE command.
Postgres bulk load (COPY FROM) command assumes this column order.

Sure, but wouldn't the o/r mapper produce the SELECT statement WITH
column names? And wouldn't it expect the data in that order?

I.o.w.: it's not important, as long as the o/r mapper produces the
select, as it then knows the order of the columns in the statement and
uses the same order for the ordinal calculation to retrieve the values.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Jon Skeet [C# MVP]]

There is order of columns in CREATE TABLE command.

Could you be a bit clearer about what you're talking about: SQL
columns or C# properties?

Properties exist in the C# code - why do you care what order they're
declared in?

Jon

 

[Andrus]

Properties exist in the C# code - why do you care what order they're

declared in?

I have used many years SELECT * command and like the order of columns
returned by this.
This is native for me: primary key columns first, then most important
properties.

I'm expecting the same column order in generated code and in object
inspector.
This makes my application debugging a lot easier. I have 50
columns/properties.
It is tedious to search for id property among 50 properties if id is random
and different place in
different entity types.

VSE 2008 debugger show only few first bytes of ToString() when mouse in over
object, no magnifier icon.
Even when I copy property to notepad, whole name is not displayed, ...
appears in end.

Andrus.

 

[Jon Skeet [C# MVP]]

I have used many years SELECT * command and like the order of columns
returned by this.

What makes you think that that also holds for the declaration order of
properties, however?

This is native for me: primary key columns first, then most important
properties.

I'm expecting the same column order in generated code and in object
inspector.
This makes my application debugging a lot easier. I have 50
columns/properties.
It is tedious to search for id property among 50 properties if id is random
and different place in different entity types.

How hard is it to add a watch of foo.ID?

Really, I don't think that trying to assume that the declaration order
of properties in C# will be consistent or meaningful is a good idea.