Order of arguments in FetchUsingPK changed in templates???

Posts   
 
    
Rob
User
Posts: 54
Joined: 17-Sep-2004
# Posted on: 13-Jan-2015 03:30:36   

I potentially have a big problem to deal with.

When I very recently updated my LLBLGen generated code from 2.6 to 4.2 it all seemed to work well. However, it now appears that the order of the arguments for the FetchUsingPK() method have changed on me!!!

I have very many calls to those methods and it will take days to go through them all. Can somebody please tell me in which order the parameters will appear now, as opposed to before?

I would also very much like to know why it has changed! And if there is some setting I can make somewhere to make the generated code use the same order of the parameters as before.

Regards

Rob

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 13-Jan-2015 05:53:12   

It's a breaking change documented in the docs:

Breaking changes v3.0

Templates Fields have no index anymore. This leads to a problem in which order PK fields and UC fields are emitted into the method signatures. The fields are ordered by their name, ascending. This could lead to a breaking change when migrating v2.x code to v3.x when a compound PK or UC with two or more fields with the same type are used. You have to examine calls to the fetch methods using PK and UC directives as well as CTor calls to entities with a PK of 2 or more fields.

However, you can set the field ordering manually, if you want to. See this documentation section to learn how.

David Elizondo | LLBLGen Support Team
Rob
User
Posts: 54
Joined: 17-Sep-2004
# Posted on: 13-Jan-2015 06:03:22   

Thanks daelmo

I guess I should have seen that myself, but I somehow missed it.

So at least now I know the parameters appear in alphabetical order. There is some comfort in that as this applies to insignificant many-to-many tables where usually the only columns are the two PKs. I normally name those TableA_TableB and usually in alpha order. Unfortunately I deviate from that sometimes when one table is a lot more significant than the other.

So out of my 845 calls to .FetchUsingPK() I "only" need to change those where the order of the two tables in the name is not in alpha order. That brings it down a whole lot.

Thanks again

Rob

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 13-Jan-2015 06:57:59   

Of course you always have the option to reset the ordering to the original position in the Db's table (same documentation link posted above) :

Automatically set the field order With an existing project, it can be tedious to set the field order on every entity by hand. LLBLGen Pro offers the ability to set the field order based on the ordinal order of the mapped target fields in the table / view. How LLBLGen Pro does this depends on how you want to work.

For working database-first, this is done during a catalog refresh if the project property ResetFieldOrderBasedOnTargetOrderAtRefresh is set to true (default is false). When reverse engineering, new entities created through reverse engineering will only get their fields ordered after the ordinal ordering of the fields of the tables/views they're mapped on if the project property UseCustomFieldOrderingOnNewElements is set to true (false by default).

For working model-first, this is done when a new entity is defined and if the project property UseCustomFieldOrderingOnNewElements is set to true (default is false). Fields added to a new entity will automatically get a field order (the last known field index + 1) if that setting is set to true. This works regardless of how you add the field: in the entity editor or through QuickModel or for example through adding a relationship and it will create a foreign key field in the entity.

Another option is to refactor your method calls using a smart VSNet regex Find/Replace operation. A trivial example would be (not tested):

Find: {.}order{.}.FetchUsingPK({[0-9]+}, {[0-9]+}) Replace: \1order\2.FetchUsingPK(\4, \3)

Above example would find all entity variables that contains the word "order" and switch their numeric PK parameters.

David Elizondo | LLBLGen Support Team