Pablo wrote:
Otis,
the solution (how ugly it may sound/look) used here simply works. It implements the use-case scenario database-first. IMHO LLBLGEN should support the same thing if desired by the user, as it did in past versions! (It worked perfectly uptil v2.6)
ah, so it should get rid of a validation system and go back to the v2.6 system which could lead to problems at runtime, which we then have to answer here on the forums, not you. It's easy to say 'it should do this', while at the same time you don't have the responsibility for the downsides of what 'this' is. If it was simple, we'd have fixed it long ago, like I said elsewhere. It's not, unfortunately. You don't seem to believe me, which saddens me, but what can I do? In the past 12 years I'm now working on the code base I've always put the customer first, if they have a problem I would invest to solve it and make their lives a tiny bit better, but I can't do things which are impossible. Like I said elsewhere: an invalid model can't be proven to migrate successfully so using it is then a gamble, which means if there are problems we have to answer them and solve them, as our code caused it, not you. So we choose to use code which can be verified, as a valid model can be migrated to a different schema. You're not happy with the downsides of this choice, I get that, however it is what it is.
For what it's worth, there is more time wasted in the threads you started based on this issue than it took to correct the pk issue in the project by far.
You looking away from this issue simply confirms that Database First is a dead-end street as far as llblgen is concerned? Reason: trust me, it's not possible. Right!?!
I never said those things in that context, so don't make it appear I did. I explained a couple of times why things are the way they are and that the particular issue you run into is actually an edge case, see the link above. Database first isn't a dead end street, it's one of the ways to define a model. There is a small issue which you ran into, which has several ways to correct it, you want to do it another way, which isn't possible, as explained elsewhere and you keep insisting it is.
Like I said, I wished I could add this, but that's not possible: a model has to be valid to be migrated. In v2 the term 'valid' model didn't exist as there was no validator AND the model did accept entities without a PK. As I said elsewhere if that rule would have been present there already, it would have been a problem in v2 too.
We'll see where this leads us ...
For the record: I also don't LIKE to repeat myself ...
I said that to not have to type it here again.
I don't know what's wrong here, I clearly explained why things are the way they are, that they're not ideal, that I understand your frustration but that it's also a minor issue which has some ways to fix it. I also don't know what you mean with 'We'll see where this leads us ...'. If you're afraid we'll kill off database first, you are mistaken: we'll never do that, as a lot of our customers work that way.