Select Distinct with the new models
Developer Preview
That would only be implementable as a group by!
You are right there, brain no worky for a minute. What we are using often is a COUNT(DISTINCT) or selecting distinct by a single column which you are right, removes the ability to get the primary key.
I am fine using non-model based results for things, we had to use AR all the time in EE 2.x stuff even using our own custom models, but where i am trying to get is a weather-able position that i wont have to change code a million times if you guys begin to transform the structure of the first party tables. This is honestly how the first mention of using models read to me: “Use models to access everything because we are going to make a lot of structural changes and just have it invisible to the first party models.”
Did i understand that incorrectly or its just a setup to get us ready for EE 4.x’s chucking of the legacy folder and major first party table changes occur then?
Right now in our conversions a lot of our decisions come to “Lets just use CodeIgniter active record until there is a better solution we can use because Models cannot do ‘X’ for us and there is no AR replacement yet.”
i am trying to get is a weather-able position that i wont have to change code a million times if you guys begin to transform the structure of the first party tables
We definitely have the same goal then! I think everyone is over updates breaking left and right.
Use models to access everything because we are going to make a lot of structural changes and just have it invisible to the first party models.
That is the plan, although it will be gradual. I was talking to some people at the conference about this - raw queries are perfectly fine on your own tables. The crux of the problem on our tables, is that if you do a complicated query on one of them we’re potentially going to have a hard time getting a reasonable translation that won’t break your code or make it super slow.
Really, the big offending tables here are channel field data, member field data, and member groups. And I do realize those are big ones in terms of third party interest. The problems: channel field data keeps running out of columns, member groups need a split on the site id so that they have a primary key, and member field data is just inconsistently named (that’s the easy one to work around). And since we want more flexible field assignments you can expect that - in the very least - some additional pivot tables will have to show up.
As for 4.0, at the current rate I don’t think it’ll get rid of all the legacy stuff. It’ll start to phase it out, for sure. We’re trying to take a fairly reasonable and measured approach. A fair number of the old models will probably start to go, especially the useless ones. Similarly the lesser used and replaced libraries. We ourselves still have a lot of dependencies, especially in our frontend code. We won’t be seeing an rm -rf legacy/ any time soon. And we won’t remove something that clearly still needs a replacement (e.g AR), or where we didn’t provide a replacement in time for you to start using it.
Still, I would like to get you to a point where you’re not worried about updates. Do you have a sense of what first party tables or queries on them you’re particularly worried about? The more concrete the example, the better.