You have probably heard that Entities are Tables now? If not, have a look here:
Well, am I thrilled about it? Am I concerned about it?
Quite frankly, we should all get used, by now, to all those changes in the product names and/or in the terminology around Microsoft products. Sometimes, those changes are successful, and, sometimes, they are not. One thing is certain – they did happen in the past, they keep happening, and they will be happening in the future.
And I just think I reached the point where it does not matter to me what the name is, since:
- I don’t know the reasons behind renaming (other than vague references to the users feedback etc)
- If anyone tells me they don’t like new names, I’m just going to say “it’s not worse or better than it used to be. As long as this is what Microsoft will be using these days, I’m fine with that”
For example, in case with entities and tables, we’ve all got used to “entities” over the years. But the concept is rather vague to be honest. It’s not a table, it’s not a view… it’s some combination of metadata and business logic.
It is vague to the point where even XRM SDK has it wrong. There is “Entity” class in the SDK, but, realistically, it should have been called EntityInstance. Or, maybe, EntityRecord. Or even just “Instance”.
If it’s easier to call it Table when discussing these concepts with new clients/developers, so be it. Although, of course, in this new terminology we will likely always have to add “well, it’s not quite the same table you’d have in SQL. But it’s a good enough approximation”
In that sense, it seems I almost became immune to the renaming virus. I know it’s there, but I’m staying cool.
Although, on a more personal level, this change may affect me, and not in the best way.
See, half a year later, when new terminology settles in, everyone will be searching for “CDS tables…” in google. But all my blog posts up until now used different terminology, so there will be two immediate consequences:
- Those older posts might stop showing in the search results
- Even if they do show up, blog readers (especially those new to Power Platform)might actually get confused even more when they start seeing old terminology
Almost inevitably, there will be some period of adjustment, when old and new terminology will have to co-exist, and, yet, every Power Platform user/client/developer would have to be familiar with both sets of names to be able to understand older posts/articles/blogs/or recordings.
From that perspective, it might be quite a conundrum, of course. Although, everyone is going to be in this boat, so we might, as well, simply keep sailing – just need to adopt new terminology and start using it moving forward.
Thanks, Alex. I pretty much agree with everything you said, although there is one exception – and that’s with “Column, columns.” I feel like the terminology “Field” and “Attribute” provided a way of being a bit more precise in our language – whereas a “Field” could refer to the use of an Attribute on a form, while an Attribute could refer to the underlying database attribute – or column in SQL. This way we could refer to “Field labels” and “Attribute Display Names” separately, since as we know you can change one or the other or both. Now they are both just “Columns.” I think they may have done this to appeal to the citizen developer – although if I were them I’d slow down a little with the changes going forward, or else these citizen developers will get a bit muddled…
I hear you. Although, I guess we could call an attribute a column, and a field could be called “control”. Which is how it is in the client side xrm and/or in the form designer when we are choosing a control to use. I mean it makes sense that a set of records is called a table, and, then, every row in that table is comprised of columns… well, looks like I’m getting used to it after all:)