Oder of PK field in generated method changed?

Posts   
1  /  2
 
    
JayBee
User
Posts: 269
Joined: 28-Dec-2006
# Posted on: 27-Jul-2010 22:36:36   

Hi,

I am trying to upgrade a website of mine to LLBLGen 3.0. Also the database is changing from SQL SErver 2005 to 2008 R2. Also I am upgrading from VS 2008 to 2010. I have downloaded the latest version of LLBLGen today (27-7). I am using SelfServicing.

In the version running LLBLGen 2.6 against a SQLServer 2005 DB, I was able to create an new entity of a certain table using

XXXEntity test = new XXXEntity(field1, field2).

Where field1 and field2 together define the primary key. In the table definition in SQLServer field1 precedes field2.

After defining the tables in SQL Server 2008 and generating a SelfServicing project the order of the fields has changed. I can only create a new entity using

xxxEntity test = new XXXEntity(field2, field1).

Is there a way to influence the order of the fields? I tried changing some settings without any result.

Best regards,

Jan

MTrinder
User
Posts: 1461
Joined: 08-Oct-2008
# Posted on: 27-Jul-2010 22:45:05   

Sorry, but due to changes in v3 this is a breaking change for your code. Fields are now ordered by name (ascending) and not by field index, and there is no setting to control this.

I'm afraid you will need to modify your code to reflect this change.

Sorry about this, but sometimes changes like this are unavoidable.

Matt

JayBee
User
Posts: 269
Joined: 28-Dec-2006
# Posted on: 27-Jul-2010 23:00:50   

Hi Matt,

I appreciate your quick reaction, but am not happy with the answer. I'll probably have to change my code, which is easy if the PK was define using different types of fields, e.g. number and string.

You say some changes are unavoidable. IMHO this is not unavoidable but an implemenation choice made by SD. I think the order should allways be the order in the table definition in the database.

Best regards,

Jan

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 28-Jul-2010 05:25:41   

Hi Jan,

It's unfortunate you run into this, but it's a necessary change. Such change won't be roll-backed so you have to change your code just once.

What we will add in the future is a way to specify an ordering of the entity fields in the designer. If that's based on an ordinal list or your own preference / grouping needs, that's up to you.

The ordinals are in the meta-data, they're just not affecting the generated code. The order in which properties are enlisted is also not necessarily the one of the fields list: in .NET there is no ordering of properties when you reflect over them. At the moment, the runtime looks into the fields list and this is the order in which the properties are shown in the 'automatic' scenario, but in many cases you want to change this anyway: some fields aren't suitable to show up, others need to be repositioned etc. That a legacy database has the columns in a certain order is not something an application should be based on. One ordering of the columns in the db will have a big impact on your application at runtime all of a sudden.
" So, again sorry, you have to chance your code as described in the "migrating your code" manual's section.

David Elizondo | LLBLGen Support Team
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 28-Jul-2010 12:46:21   

We made this change because you can have multiple database types in a project now, e.g. an entity mapped to a table both in sql server and oracle, and ordinals could be different. As this is unsolvable if the order of a field in the entity is based on the order in the target table, we decoupled this.

One could argue that if there's just 1 db type in the project, the ordinals of the fields could be taken into account, but that would create extra code paths in the code, and it would be a problem again if you added a 2nd db type later on: what to do with the field order?

This pops up in the following scenarios: 1) with compound PK fetches (...FetchUsingPk(...) / initializations (Ctor calls). So you have to check only the usage of the ctor of entities which have a compound PK and the FetchUsingPk calls. To find all entities with a compound PK in the designer, open element search, select 'Entity' at the top and the following as query: return p.EntityModel.Vertices.Where(e=>e.IdentifyingFields.Count() > 1);

2) with UCs which have multiple fields. Here you have to check where you use these UCs, on the entities which have them. To find all entities which have UCs with multiple fields, open element search, select 'entity' and specify the following as query: return p.EntityModel.Vertices.Where(e=>e.UniqueConstraints.Any(uc=>uc.Count() > 1));

this will return all entities with Ucs with multiple fields. With UC's it easier as the method name already changed as well, so if you didn't get any errors there, the UCs are all ok.

This might help in tuning down the search for code breakage. You can further limit your search with extra filters perhaps on types of the fields, but I don't know how much entities you have which are affected by this.

As you can see, normal single field pks/ ucs don't result in this problem, so it's not as if all projects are broken all over, just the entities which fall into the above 2 categories. In your project this might be more than a couple, but the above queries might help track down the code more easily so refactoring the code is less time consuming.

Frans Bouma | Lead developer LLBLGen Pro
happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 11-Oct-2010 15:41:56   

So I converted some apps to 3.0 and they finally compiled. Awesome. But they're not running correctly. Hmmmm. WTF is this? Multi-column primary key objects are now broken. Aaarggh!!!! This sucks.. Actually, this really really sucks. I just can't understand the decision making process behind this. Some other LL decisions I've found questionable and have just had to accept, but this one just really takes the prize.

And I don't agree/understand with any of your decision behind why you did it. What percentage of your clients actually generate against multiple db types? Is there data that shows you ONLY screwed over the minority of your clients? Do the majority of your clients really develop against two or more databses at the same time for the same project? And so what if different databases have a different order??? You had an index property that visible in 2.6. Why coudn't you have kept that for your ordering and add a feature to let your users decide the ultimate order?

Now we have tons of multi-column primary keys that just happen to compile because the data types just happen to match. And now we have to go find all these. Now developers need to actually look at intellisense to see what order the fields are in and ignore their natural habit of what they primary keys would normally be in. Does that make sense?

Is there some fix I've missed in some other post? If so, then I take everything back. If not, then I have to ponder what other wierd decision making you will do down the road.

You really screwed us over on this one.

happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 11-Oct-2010 15:44:30   

MTrinder wrote:

Sorry about this, but sometimes changes like this are unavoidable. Matt

Interesting, you say it's unavoidable but another support team member after you talks about a feature to bring ordering back into the designer.

So it sounds to me like it was avoidable, you just didn't put the effort into making it avoidable.

And so when/if that features comes to light, we'll have to make changes TWICE to get the code back to what developers naturally expect.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 11-Oct-2010 17:24:07   

happyfirst wrote:

So I converted some apps to 3.0 and they finally compiled. Awesome. But they're not running correctly. Hmmmm. WTF is this? Multi-column primary key objects are now broken. Aaarggh!!!! This sucks.. Actually, this really really sucks. I just can't understand the decision making process behind this. Some other LL decisions I've found questionable and have just had to accept, but this one just really takes the prize.

And I don't agree/understand with any of your decision behind why you did it. What percentage of your clients actually generate against multiple db types? Is there data that shows you ONLY screwed over the minority of your clients? Do the majority of your clients really develop against two or more databses at the same time for the same project? And so what if different databases have a different order??? You had an index property that visible in 2.6. Why coudn't you have kept that for your ordering and add a feature to let your users decide the ultimate order?

I can understand why you are upset but it's the way it is, it's a breaking change for v3 which won't be reverted, simply because it will cause problems with multi-db projects. The main point is that multi-db projects is a feature of v3 too, something which some clients requested, but it's also a feature which doesn't leave room for 'workarounds': order has to be the same in any case, and although the decision has downsides, alternatives had downsides too, so we had to pick one. So we did.

Now we have tons of multi-column primary keys that just happen to compile because the data types just happen to match. And now we have to go find all these. Now developers need to actually look at intellisense to see what order the fields are in and ignore their natural habit of what they primary keys would normally be in. Does that make sense?

There's a way to find all compound PK fields which are ordered in a different way than in v2.6. See: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=18633

it shows you how to find the entities which have PK fields which are generated in an order which is different from the ordinal order. This directly gives you the list of entities which you have to check in your own code. This makes it easier to migrate your code.

Please do understand that in the past 7 years we have avoided breaking changes a lot and do everything we possibly can to avoid them, and this decision wasn't something we made after careful consideration. We did and do understand that it would give problems for customers, but the alternatives would be bad as well, perhaps not for you but for others it would, as there's not even a 'right' way to do multiple db projects with entity fields ordered in an ordinal fashion.

Is there some fix I've missed in some other post? If so, then I take everything back. If not, then I have to ponder what other wierd decision making you will do down the road. You really screwed us over on this one.

I think you should lower your tone a bit, don't you think?

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 11-Oct-2010 17:33:00   

happyfirst wrote:

MTrinder wrote:

Sorry about this, but sometimes changes like this are unavoidable. Matt

Interesting, you say it's unavoidable but another support team member after you talks about a feature to bring ordering back into the designer.

Ordering will be back for visual purposes, i.e. people like to have 'FirstName' and 'LastName' together in an entity, visible in the designer, even though ordering doesn't make any sense logically. There will be an ordering system which allows you to do this, but it has NO effect on the generated code.

So it sounds to me like it was avoidable, you just didn't put the effort into making it avoidable.

Sorry, but if you think we're a bunch of lazy whiners then you're mistaken. We don't make decisions which will break code a lot like we're flipping a coin.

We want to change a lot of things in the runtime, but we can't anymore, because it's too late, there's so many code out there which would break terribly if we for example kick out the named collections for selfservicing and revert to a simpler EntityCollection<EntityType> format.

We do know what breaking code means, and therefore try to avoid it but it was a choice between: 1) not add multi-db projects or 2) use alphabetical ordering of pk fields in code

as multi-db projects is something which greatly helps people, in many projects to come, plus not all entities have compound pk's (sometimes no entity has a compound PK) it was a decision we stand behind firmly, however we do know and understand the end result of that decision might upset some people. All is not lost however, see the link I posted.

And so when/if that features comes to light, we'll have to make changes TWICE to get the code back to what developers naturally expect.

No, that's why it won't have any effect for generated code, as field ordering doesn't make any sense for the generated code, only for method signatures, i.e. ctors and fetch methods in selfservicing.

You rant a lot, and that's ok, I do that too on other forums, I understand the necessity of ranting simple_smile . You should consider however that changing your PK in the entity: Foo: [a* (int), b* (int), c (int), d (string)] to: Foo: [a* (int), b (int), c* (int), d (string)]

also breaks your code, in the exact same way.

Frans Bouma | Lead developer LLBLGen Pro
happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 11-Oct-2010 17:43:44   

Otis wrote:

There will be an ordering system which allows you to do this, but it has NO effect on the generated code.

This is what I still don't understand.

So now your order in generated code is always alphabetical? It doesn't match the ordinal order (the prior default). And yet everything still works. That makes me think that the generated code could be in any order

So why can't user's choose the order in generated code?

If I can better understand why this change is absolutely unavoidable, then maybe my ranting is too much, but then again, i got screwed over a feature I didn't ask for.

Earlier you said

Otis wrote:

One could argue that if there's just 1 db type in the project, the ordinals of the fields could be taken into account, but that would create extra code paths in the code, and it would be a problem again if you added a 2nd db type later on: what to do with the field order?

Please explain "extra code paths" ?

And what's the problem "if" a 2nd db is added later?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 11-Oct-2010 17:55:51   

happyfirst wrote:

Otis wrote:

There will be an ordering system which allows you to do this, but it has NO effect on the generated code.

This is what I still don't understand.

So now your order in generated code is always alphabetical? It doesn't match the ordinal order (the prior default). And yet everything still works. That makes me think that the generated code could be in any order

All pk fields will always be generated in alphabetical order. Class properties have no ordering, so the only place where ordering pops up is with ctors / methods where pk fields are emitted or Unique Constraints fields are emitted (same issue). To have an ordering which is predictable, we chose alphabetical.

Ordering of compound pk fields / uc fields always is a weak spot btw: in v2.6, if you change the ordering of fields in the table, the code also breaks (where? you can't tell, there's no search).

So why can't user's choose the order in generated code?

If I can better understand why this change is absolutely unavoidable, then maybe my ranting is too much, but then again, i got screwed over a feature I didn't ask for.

With reverse engineering entities, how would you pick the ordering? Mind you, in the designer there is no ordering, the designer has no preference how fields are ordered, as there's none. It displays fields in alphabetical order in the project explorer and in the entity editor the default sorting is the field name, but that's arbitrary, as fields in an entity have no order. As no order means a problem for generated code, we picked an order for you: alphabetical. We also could have picked target field ordinal like in v2.6. Then you add a second db to the project and what should happen then? what if the order is slightly different? Then, there's NO solution, as there's no 'workaround': the designer then has to choose, so it e.g. chooses the first db (which might be your second db added), and later on you decide to remove it again, code changes again.

This we didn't want: we wanted a single transition, so people would never have to make a transition again.

You might say: "but let me choose the ordering, so when I migrate, I can select the order", but that's a one time thing, plus manual labor which you always have to do after reverse engineering an entity, also in future projects. Now you have a predictable ordering in the code: alphabetical.

And yes, you might not use multiple db projects now, but you might in the future. With a migration to a new version, with breaking changes, there are always things which suck and if you don't need it, it sucks even more. Like we don't like MS' choice of not automatically run a .net app on .net 4 if .net 4 and .net 3.5 is installed, like they did when .net 2.0 was installed + .net 1.1 and you ran a .net 1.1 app. Now we have to either create two builds (bad) or ship a lame .net 4 runner which keeps a dosbox open. Nice? no. Should I rant all night long? If it would help I certainly would. But unfortunately it won't help, as MS wont change it as they had their reasons. I might not like them, but I do understand them. I don't like the situation it leaves us in, but it won't get better for us if I keep on ranting it sucks. So we adapt and sort it out.

I can understand you'd want to rant all night long about this change. But I'd suggest to take a step back and really look at the list of entities the query I posted above will give you and how much work it really is (as also only compound pk's with same-typed fields are a problem).

Earlier you said

Otis wrote:

One could argue that if there's just 1 db type in the project, the ordinals of the fields could be taken into account, but that would create extra code paths in the code, and it would be a problem again if you added a 2nd db type later on: what to do with the field order?

Please explain "extra code paths" ?

1 for a single db: pick the ordinal as base for ordering, 1 for multiple db projects, where field name is the ordering factor.

I could rehash my own words again from earlier in this thread, but that is a little redundant IMHO. I'd rather like to be constructive, so I'll ask: did the link I posted above help you? did the query result in a lot of entities or just a couple and did you find it usable to track down breakage? (as it also only needs tracking when the pk fields have the same type, otherwise re-ordering due to the new ordering with different typed fields would cause compile errors.). Use shift-F12 in VS.NET when the cursor is on the ctor signature/uc method signature to find callers of a ctor / UC method to quickly find code you might want to migrate.

Frans Bouma | Lead developer LLBLGen Pro
happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 11-Oct-2010 18:12:23   

Otis wrote:

Ordering of compound pk fields / uc fields always is a weak spot btw: in v2.6, if you change the ordering of fields in the table, the code also breaks (where? you can't tell, there's no search).

Why does ordering need to be "predictable" instead of just matching on names?

Otis wrote:

1 for a single db: pick the ordinal as base for ordering, 1 for multiple db projects, where field name is the ordering factor.

So the extra code paths are on your end, not ours? So there is a solution, you just didn't want to code it?

Otis wrote:

I could rehash my own words again from earlier in this thread, but that is a little redundant IMHO. I'd rather like to be constructive, so I'll ask: did the link I posted above help you? did the query result in a lot of entities or just a couple and did you find it usable to track down breakage? (as it also only needs tracking when the pk fields have the same type, otherwise re-ordering due to the new ordering with different typed fields would cause compile errors.). Use shift-F12 in VS.NET when the cursor is on the ctor signature/uc method signature to find callers of a ctor / UC method to quickly find code you might want to migrate.

Yes, your link helped. But, this still all sucks. Now our developers have to use intellisense to learn the "NEW" LLBL way of how our SINGLE database works. Looking at the designer sucks too because nothing is where we expect it.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 11-Oct-2010 18:32:13   

happyfirst wrote:

Otis wrote:

Ordering of compound pk fields / uc fields always is a weak spot btw: in v2.6, if you change the ordering of fields in the table, the code also breaks (where? you can't tell, there's no search).

Why does ordering need to be "predictable" instead of just matching on names?

because you now can predict what the order will be, without the order of fields in the target of the entity (which is abstracted away by the entity). Do field order change in the table? Do you map the entity onto a view now (with different ordering)? No problem, ordering is the same.

Otis wrote:

1 for a single db: pick the ordinal as base for ordering, 1 for multiple db projects, where field name is the ordering factor.

So the extra code paths are on your end, not ours? So there is a solution, you just didn't want to code it?

Extra code paths in our code is always bad, as it means that bugs could creep into the code undetected. But that was hardly the main reason, as I've explained now a dozen times.

Btw, you again suggest we're lazy. I'm starting to get fed up by that insinuation as nothing is more further from the truth.

Otis wrote:

I could rehash my own words again from earlier in this thread, but that is a little redundant IMHO. I'd rather like to be constructive, so I'll ask: did the link I posted above help you? did the query result in a lot of entities or just a couple and did you find it usable to track down breakage? (as it also only needs tracking when the pk fields have the same type, otherwise re-ordering due to the new ordering with different typed fields would cause compile errors.). Use shift-F12 in VS.NET when the cursor is on the ctor signature/uc method signature to find callers of a ctor / UC method to quickly find code you might want to migrate.

Yes, your link helped. But, this still all sucks. Now our developers have to use intellisense to learn the "NEW" LLBL way of how our SINGLE database works. Looking at the designer sucks too because nothing is where we expect it.

You ALWAYS have to look at the method signature you call, and in v2.6 developers also had to check in which order fields were specified, as the fields were in an order. The tone you use here suggest you're faced with hundreds of entities which now break your code, which also means your developers don't remember all pk field orders in the tables, (the leading ordering for v2.6) so they too had to look at the order of the fields in ctors and uc fetch methods. I.o.w.: why is this suddenly 'new'?

Frans Bouma | Lead developer LLBLGen Pro
happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 11-Oct-2010 18:32:49   

Otis wrote:

With reverse engineering entities, how would you pick the ordering? Mind you, in the designer there is no ordering, the designer has no preference how fields are ordered, as there's none. It displays fields in alphabetical order in the project explorer and in the entity editor the default sorting is the field name, but that's arbitrary, as fields in an entity have no order. As no order means a problem for generated code, we picked an order for you: alphabetical. We also could have picked target field ordinal like in v2.6. Then you add a second db to the project and what should happen then? what if the order is slightly different? Then, there's NO solution, as there's no 'workaround': the designer then has to choose, so it e.g. chooses the first db (which might be your second db added), and later on you decide to remove it again, code changes again.

I don't understand what's wrong with reverse engineer first database, defaults to that order. Add a 2nd database, just keep whatever order is currently in place. Remove the first db, still, just keep what order is currently in place?

What if the 2nd db had the columns already in the right order? Then it would have just worked out? Alphabetical still not necessary?

Why not place a requirement that the 2nd db has to have the fields in the same order?

What about an optional "manual" step for that 2nd db if the fields don't match the existing order for specifying the mapping from the 2nd db?

What's an example of different databases and how they returned the fields in a different order?

happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 11-Oct-2010 18:39:06   

Otis wrote:

Extra code paths in our code is always bad, as it means that bugs could creep into the code undetected. But that was hardly the main reason, as I've explained now a dozen times.

Btw, you again suggest we're lazy. I'm starting to get fed up by that insinuation as nothing is more further from the truth.

You are the one that keeps saying "lazy".

It's also being stated that this was unavoidable but it does seem that there were ways to avoid this.

You simply had your reason for choosing not to. I'm not able to grasp just how much extra code it would have really taken to avoid this.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 11-Oct-2010 18:39:15   

happyfirst wrote:

Otis wrote:

With reverse engineering entities, how would you pick the ordering? Mind you, in the designer there is no ordering, the designer has no preference how fields are ordered, as there's none. It displays fields in alphabetical order in the project explorer and in the entity editor the default sorting is the field name, but that's arbitrary, as fields in an entity have no order. As no order means a problem for generated code, we picked an order for you: alphabetical. We also could have picked target field ordinal like in v2.6. Then you add a second db to the project and what should happen then? what if the order is slightly different? Then, there's NO solution, as there's no 'workaround': the designer then has to choose, so it e.g. chooses the first db (which might be your second db added), and later on you decide to remove it again, code changes again.

I don't understand what's wrong with reverse engineer first database, defaults to that order. Add a 2nd database, just keep whatever order is currently in place. Remove the first db, still, just keep what order is currently in place?

what's 'second database' when you have just 'databases' ? That implies there's an ordering in the databases, which isn't the case (as they're treated equally). If you again remove a second database, why is keeping that ordering suddenly 'good'? it's based on nothing, only what once was there. What to do with a new table?

What if the 2nd db had the columns already in the right order? Then it would have just worked out? Alphabetical still not necessary?

yeah and then 1 table doesn't have it, then what? "Oh just change the table" why?

Why not place a requirement that the 2nd db has to have the fields in the same order?

Because that's a silly requirement as it's unnecessary, as it's only required for people who migrate from v2.6 and have compound PKs and don't want to migrate their code once.

What about an optional "manual" step for that 2nd db if the fields don't match the existing order for specifying the mapping from the 2nd db?

That's creating a lot of complexity for a situation that's not related to it, mind you: code is a projection of the model, not equal to the model.

As this doesn't go anywhere, I'll close this thread unless you have constructive things to add. Again, you may rant because you're upset, but there's also a time for taking the step back, accept the situation and move on. Suggesting we're lazy also doesn't help your point, to be honest.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 11-Oct-2010 18:47:09   

happyfirst wrote:

Otis wrote:

Extra code paths in our code is always bad, as it means that bugs could creep into the code undetected. But that was hardly the main reason, as I've explained now a dozen times.

Btw, you again suggest we're lazy. I'm starting to get fed up by that insinuation as nothing is more further from the truth.

You are the one that keeps saying "lazy".

I quote: "So there is a solution, you just didn't want to code it? "

You have no idea how much problems we've solved in v3 and how far we went to make things predictable, always working so also in edge cases etc. etc. So if you then suggest we simply didn't want to implement a solution to a breaking change of this magnitude, it can only be because we were lazy.

as I've explained above, there is NO SOLUTION.

It's also being stated that this was unavoidable but it does seem that there were ways to avoid this.

Ah, so we had to pick the option of creating a mess because you think that's the better option? Well, sorry, but no, we chose to not create a mess but bite the bullet and introduce this, sad, breaking change, like we've introduced other breaking changes, which you didn't ran into but others might/will run into. That's also why we didn't introduce the breaking change on a point release but on a major release, for which people have to upgrade.

Frans Bouma | Lead developer LLBLGen Pro
happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 11-Oct-2010 18:49:34   

Otis wrote:

You ALWAYS have to look at the method signature you call, and in v2.6 developers also had to check in which order fields were specified, as the fields were in an order. The tone you use here suggest you're faced with hundreds of entities which now break your code, which also means your developers don't remember all pk field orders in the tables, (the leading ordering for v2.6) so they too had to look at the order of the fields in ctors and uc fetch methods. I.o.w.: why is this suddenly 'new'?

In 2.6, the order was natural and just expected. We do have a lot of tables with multi column pkeys and lots of code written. Our developers do know the primary keys and now they're fixing them all up. Now they need to learn to avoid their natural tendency to send parameters through based on the natural order. They need to relearn the alpha order. Maybe to you this is not a big deal, but it is.

I'm partially confused what you mean about 2.6 ordering. At least for us, the 2.6 order is what we expected. It's what we just naturally type everywhere.

Then I have other projects built with our own custom generator and that generator does build using the natural order. So now developers for the first time, need to be careful what they type, in what order, depending on the project.

happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 11-Oct-2010 19:05:25   

Otis wrote:

as I've explained above, there is NO SOLUTION.

But you've already stated there is a solution, just one that was not acceptable to you. It would have left you with a "mess".

Well, depends on who's defining "mess". I now have a mess and need to relearn things.

Again, you may rant because you're upset, but there's also a time for taking the step back, accept the situation and move on. Suggesting we're lazy also doesn't help your point, to be honest.

I've taken the step back and acceptd it. It still sucks.

My biggest fear is that you will just get more comfortable with more breaking changes down the line in the name of growth.

And again with the lazy. That's your interpretation, not what I implied. If you were to have admitted a posssile solution would only take a day or so, then yeah, maybe I'd of used lazy. If instead it were to have taken a week or two or even a month, with all the extra testing, cleaning up the "mess", then I wouldn' use lazy. But it would have represented a possible solution, just one you didn't choose to take.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 11-Oct-2010 19:11:07   

happyfirst wrote:

Otis wrote:

You ALWAYS have to look at the method signature you call, and in v2.6 developers also had to check in which order fields were specified, as the fields were in an order. The tone you use here suggest you're faced with hundreds of entities which now break your code, which also means your developers don't remember all pk field orders in the tables, (the leading ordering for v2.6) so they too had to look at the order of the fields in ctors and uc fetch methods. I.o.w.: why is this suddenly 'new'?

In 2.6, the order was natural and just expected. We do have a lot of tables with multi column pkeys and lots of code written. Our developers do know the primary keys and now they're fixing them all up. Now they need to learn to avoid their natural tendency to send parameters through based on the natural order. They need to relearn the alpha order. Maybe to you this is not a big deal, but it is.

what's the 'natural order'? If you have a lot of tables, I find it hard to believe the developers know the PK fields of all of them and the order in which they are defined. There's only a problem when: - there's a compound PK or multi-field UC - multiple fields in PK /UC have the same type - alphabetically they're in a different order than the targets they're mapped on.

'assuming' the developer knows the PK order of an entity is IMHO asking for problems, the developer always has to look at the order in which the parameters are defined in a method call, ctor etc.

I'm partially confused what you mean about 2.6 ordering. At least for us, the 2.6 order is what we expected. It's what we just naturally type everywhere.

The order in which fields were ordered in v2.6 was the ordinal order of the table the entity was mapped on. This is not there anymore in 3.0 as the table field order doesn't dictate an ordering. See above for the many reasons why that isn't.

Then I have other projects built with our own custom generator and that generator does build using the natural order. So now developers for the first time, need to be careful what they type, in what order, depending on the project.

Why don't they just look at the method they call? Isn't that how things work in all other methods they call? things change, every UC method they use, every CTor they call, it might change, and other people might change things and they don't expect it, so they'll make mistakes if they assume things to be the way they are.

Let me repeat myself: no we don't like this at all, yes we can understand people when they don't like it either, but we had no choice as alternatives were worse, as the choice for multiple-db projects dictated this.

We can continue this conversation till oblivion, but that last fact doesn't change as we won't kick out that feature.

What we can do in the future (but that doesn't help you now) is to offer a choice: pick one: - use the alphabetical ordering (default) - use the ordering set in the designer on the entity

only for pk fields. First one is easy for the user, as it doesn't require manual labor, the second one requires manual labor, or a setting where visual field ordering is determined from the target the entity is mapped on when created from reverse engineering. So you then have to set that setting and choose the second option.

This will always lead to a mess with multiple db's, sooner or later. So people will then flip back to the original, alphabetical ordering. The downside is that when you do that, your own code breaks again. It will always break whenever you change the options I described above. A high price to pay for something which is in the end irrelevant: an entity has no field ordering, and to keep code predictable, the code uses a field ordering.

However whatever is added in the future, what doesn't change is the fact that developers always have to check what they call, in what order fields are stored. The more systems grow, the more this is important: change will then not cause problems, as it's predictable what changes. In v2.6 we didn't have that, we relied completely on the table, but in v3 we don't.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 11-Oct-2010 19:23:37   

My last reply in this thread.

happyfirst wrote:

Otis wrote:

as I've explained above, there is NO SOLUTION.

But you've already stated there is a solution, just one that was not acceptable to you. It would have left you with a "mess". Well, depends on who's defining "mess". I now have a mess and need to relearn things.

O/R mapping is all about correctness and deterministic behavior. A 'mess' would mean something is not correct and/or not deterministic. it might be today, but not tomorrow, or when someone makes changes. We try to avoid that at all cost. This sometimes leads to us writing cumbersome code (and trust me, we have) but that's what comes with the territory, c'est la vie.

As I've stated above, there is no solution, as there's no question with a single answer: there's only a series of situations which have all ideal ways to dealing with them, however these ideal ways are mutual exclusive. So you can only pick one and try to use it in the other situations.

We picked the choice we made for several reasons, also because entities have no ordering of fields, code does.

Again, you may rant because you're upset, but there's also a time for taking the step back, accept the situation and move on. Suggesting we're lazy also doesn't help your point, to be honest.

I've taken the step back and acceptd it. It still sucks.

of course it sucks, no-one said it doesn't suck.

My biggest fear is that you will just get more comfortable with more breaking changes down the line in the name of growth.

We will always try to avoid breaking code as much as possible, but with every new version we have to make the choice between: add feature or avoid breaking code? We don't implement a feature 'sloppy' to avoid breaking code, and if a feature is important, we will accept the breaking change, but sometimes a breaking change is too big and we won't implement the feature.

Like value types, which are new in v3: they won't come to our own runtime as we had to refactor too much code and it would break too much code. That's the price of adding something later so it has to be 'designed in': it might conflict with existing code so this might cause a problem.

Another example is skipping for paging. We use page + pagesize, not skipping. Skipping is actually better, but we have to add a lot of overloads or refactor code to break things to add it, so we don't.

Two examples of where we didn't add the feature because of breaking changes. There are many more, but I've already repeated myself enough in this thread.

Will there be breaking changes in the future? yes, very likely. Will there be breaking changes on the level of this one? I doubt it. I don't like debates like this one and especially because I do understand why you're upset, I'd be too, however there's nothing I can do today to help you.

And again with the lazy. That's your interpretation, not what I implied. If you were to have admitted a posssile solution would only take a day or so, then yeah, maybe I'd of used lazy. If instead it were to have taken a week or two or even a month, with all the extra testing, cleaning up the "mess", then I wouldn' use lazy. But it would have represented a possible solution, just one you didn't choose to take.

IF there was a solution which did solve the problem (so not a compromise), we'd have implement it. But all are compromises, the one we chose, the one you propose, what others have proposed, what we have thought of ourselves etc. etc.... every choice in this case has consequences, maybe not for you, but for others it might. (while others might not run into the problems you ran into).

Frans Bouma | Lead developer LLBLGen Pro
happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 11-Oct-2010 19:33:42   

Otis wrote:

What we can do in the future (but that doesn't help you now) is to offer a choice: pick one: - use the alphabetical ordering (default) - use the ordering set in the designer on the entity

only for pk fields. First one is easy for the user, as it doesn't require manual labor, the second one requires manual labor, or a setting where visual field ordering is determined from the target the entity is mapped on when created from reverse engineering. So you then have to set that setting and choose the second option.

This will always lead to a mess with multiple db's, sooner or later. So people will then flip back to the original, alphabetical ordering. The downside is that when you do that, your own code breaks again. It will always break whenever you change the options I described above. A high price to pay for something which is in the end irrelevant: an entity has no field ordering, and to keep code predictable, the code uses a field ordering.

Well, since it's always about adding features then that sounds great.

I agree, it doesn't help me now.

I'd pick 2. It ONLY leads to a mess if one has multiple dbs and even then, there still might not be any mess. And I still don't understand the mess on on OUR end as I don't deal with multiple dbs within the same project.

I also don't understand the manual part though. I mean, my understand of your potenial future fix is that you'll allow the user in the designer to generate the code (for pkeys) using the order from the designer. But this order could be defaulted to the ordinal order when first reverse engineered. I assume you could preserve that order when future migrating?

You keep saying predictable. Well, there's predictable to you and to developers. The ordinal order is what they would predict first. They get in the habit of typing stuff.

Are you telling me everytime you write code, every single method, you always take the time to verify what the parameters are? You don't get in the habit of knowing what those parameters are? Habits can be hard and annoying to break.

Otis wrote:

However whatever is added in the future, what doesn't change is the fact that developers always have to check what they call, in what order fields are stored. The more systems grow, the more this is important: change will then not cause problems, as it's predictable what changes. In v2.6 we didn't have that, we relied completely on the table, but in v3 we don't

And again, this is where I'm just confused but I don't want to go in circles. 2.6 took the order from the table. It displayed it, but you couldn't change it. I don't understand why 3.0 couldn't have preserved that index column, migrated it, and just kept using it INSTEAD of the table since it was already populated.

Sounds like you're going to need to add in an index property anyways to allow reordering in the designer.

JayBee
User
Posts: 269
Joined: 28-Dec-2006
# Posted on: 11-Oct-2010 21:15:20   

IMHO happyfirst has every reason to be angry. I dislike this feature too and am not looking forward to converting existing applications from 2.6 to 3.0. For now I have decided to develop new apps in 3.0 and maintain the older ones in 2.6.

Customer is king! I do not like the tone of the replies to happyfirst postings.

Regards,

Jan

iDave avatar
iDave
User
Posts: 67
Joined: 14-Jun-2010
# Posted on: 11-Oct-2010 22:51:34   

JayBee wrote:

I do not like the tone of the replies to happyfirst postings.

IMHO the tone of the posts from happyfirst are very aggresive. I know he's upset because of such change but that doesn't give him the right to be inpolite.

happyfirst
User
Posts: 215
Joined: 28-Nov-2008
# Posted on: 11-Oct-2010 23:49:23   

iDave wrote:

IMHO the tone of the posts from happyfirst are very aggresive. I know he's upset because of such change but that doesn't give him the right to be inpolite.

The tone in my posts, at least what I feel, is "extreme" frustration. This is one really bad breaking change. And not a one time change. A lasting one in the sense that certain functions will expect parameters in a non-predictable way. I never meant to be inpolite or imply lazy. And even after correcting that inference, the response back is still to once again attempt to make it seem like I implied lazy.

It just doesn't make any sense at all for the primary keys to be generated in alpha order. It's not natural or predictable. Predictable is up to each client and their developers understanding of their own project. A lot of developers (at least the ones I know) are very familiar with their databases (if not actually being the ones doing that part too) and so they're very familiar with their primary keys and what order they are in.

To me and I would bet most others, it's more natural, intuitive, and predictable to think that the call will want the master key parameter first, then the detail key.

If you have an OrderID and a LineNumber, I'd wager most developers would think to type orderID, lineNumber, not the other way around. And in one case, I have three levels, the third being subLineNumber (child of order details). Does it really make sense to have the master key (1st level) be the second in line of three? lineNumber,orderID,subLineNumber ??? That's more predictable? And what if the local variables in that function are named in yet some other alpha order. I'm sorry, but to me, it's now a big headache.

Again, I don't understand why the designer can't have some index order for what the pkeys should be in that the user can manipulate. And the default state of this order could have been migrated or it could come in naturally from the database. Maybe this feature (even though no one asked for it) should have come first before multi dbs.

Instead of an identity dialog with just a bunch of checkboxes, a different dialog with a list of fields on the left side, you can move the fields into the right side, and you can change the order of the fields on the right side. Plus that existing dialog is frustrating too now without everything being in alpha order. It's just natural and predictable to see the pkeys first. Now one needs to go find their field in that dialog.

I also don't understand the "mess" at least from our end. What, for some client, in one db, their pkeys are in one ordinal order, but in another db, they're in a different ordinal order. Is that good database design? So that particular client can't make up their mind what order they want their pkeys to be in for each database and so to avoid a mess, LL just forces everybody to go alphabetical? Clients that do everything right, by the book and keep stuff in sync have to pay the price for clients that don't want to do that?

What's more common? Developers that naturally know the order of their primary keys or clients with multi-db projects with fields not in the same order?

What's a detailed example of a scenario that this breaking change solves? or mess that it helps avoid?

1  /  2