Every Metadata Object storing anything in the database is fully packed with methods for reading and writing data. For example, I can read the catalog item like this and then write it back like this. So, why do we need queries and how are they different from the Metadata Objects’ methods?
So, this is our catalog reading and writing its data to the database. As for the queries, they support no data writing whatsoever. So, we don’t have much of a choice when it comes to this. But the data reading is supported full on, so the big question here is: which reading technique to use when?
Let’s start with implementing the same simple functionality using a query. How do I read a single catalog item with a query? This is how. I create a new Query object. And now I need to specify the query text. So I’m telling it that I need a reference to the Products catalog item that has a specific code. Now, I’m passing the code value as a parameter, executing a query, and downloading the resulting recordset from the database. Then, I need to fetch the first (and the only) record from the recordset, and only then I can get the reference and read the object. Looks like an unjustifiable overkill comparing to this very compact piece of code here, but, honestly, it’ s just a matter of personal preferences. This piece of code does exactly the same and works every bit as fast as this one. The only real difference is that the query will take you a bit longer to write. That’s it.
So, this was a simple reading example, and it looks like the Metadata Objects’ methods are winning here (by a small margin, though). Let’s take a look at some more complex example of reading, shall we? Remember what happens when we try to sell more than we have? This is what. Let’s recap how it was implemented. So, this is the query, that reads the product description and how much of the product we’re short of from the Products tabular section of the Sales document we’re posting and the Inventory register balance table. It filters out all services and ignores positive balances. Then we set the query parameters, execute the query, and by this time we have all we need inside of this collection. Can we do the same using Metadata Objects’ methods? We sure can.
OK. Let’s do the same using Metadata Objects’ methods. First, I’ m creating an array to store all the products from my document. Then I cycle through the Products tabular section lines and filter out all services, while real-deal products go to the array. Then, I need to create in-memory storage for product description-deficit pairs, so, I’ m creating this map. Then, I’ m placing the product list into the structure and passing it to inventory balance as a filter. Then I cycle through all the balances I read, filter out positive balances and add negative ones to the map. This is how I get exactly the same result. But. I definitely didn’ t win anything in terms of the source code amount. I also most definitely lost complexity-wise. In this version, I use the only object - the Query and some rather simple methods of his.
Here I had to use the array, the map, and the structure, as well as a couple of cycles to have the things done. It’s also considerably slower because it sends several queries to the database server instead of the single one. And it wasn’t even a really complicated case - simple negative balance check. There are so many intricate and entangled problems out there - in the real-world business applications. So, we definitely want to use queries for reading operations of any noticeable complexity. This is how we choose whether to use the Metadata Objects’ methods or queries.