Bottom layer of Shopnc Model, bottom layer of shopncmodel

Bottom layer of Shopnc Model, bottom layer of shopncmodel

Some time ago, a certain function was implemented, involving the query of data tables. After being tested locally and in the test environment, the process seemed to be smooth, think about whether you are about to get off work (although it seems that it is not too early), and then push it into the formal environment for the final test (I thought there should be no problem, after all, it is just a query of the data, and all the data has been tested, and the data is also well output );

Last .... Finally, unexpected things happened...

Why is the product so slow that data cannot be loaded...

According to the feedback from the product, I looked at the relevant procedures and thought it should be okay. I looked at the table field design and found that some of the fields I added should be indexed, but I didn't add them, in addition, the test is still almost as slow as it is, and almost no data can be loaded...

I looked at some configuration files in the test environment and compared the configurations in the formal environment. I didn't find any problems,

Find the problem ....

(In this case, the thinking seems to be stuck in a dead corner ..)

 

After careful investigation by the supervisor, I finally found out where the problem occurred...

It turns out that the bottom layer of the Model has a cache file containing all the table names and their primary keys (as if the program was not loaded during execution, or it is not saved to the cache file when it is saved. As a result, every time the program involves table operations, it re-queries all the tables on the server. How terrible is it...

To sum up, the following problems are returned:

1. The logic judgment on the program is not rigorous enough!

It is reflected in the log if the above cached file fails to be loaded or the data is not successfully saved to the cached file, is it faster and more accurate to identify the cause of the problem!

2. the troubleshooting method is too restrictive!

It seems that you always think about the problem at one level. It is difficult to jump out of the current thinking mode and think about the problem from another perspective. This may be your own problem! (Insufficient flexibility or experience)

3. The implementation principle of the underlying system framework is not deep enough!

It may be busy in daily development. We just stayed at a certain method and did not have a deep understanding of its underlying implementation principles,

In this case, the problem occurs, and the problem is more passive!

The above summary may not be enough, but it is important to read the source code!

 

Code snippet:

/*** Generate table structure information ** @ param string $ table * @ return */public function tableInfo ($ table) {if (empty ($ table) return false; // use if (file_exists (BASE_DATA_PATH. '/cache/fields/_ pk. php ') {$ this-> fields = require (BASE_DATA_PATH. '/cache/fields/_ pk. php ');} else {$ full_table = Db: showTables (); $ _ pk_array = array (); $ count = strlen (C ('tablepre ')); foreach ($ full_table as $ v_table) {$ V = array_values ($ v_table); if (substr ($ v [0], 0, $ count )! = C ('tablepre') continue; $ tb = str_replace (C ('tablepre'), '', $ v [0]); $ fields = DB :: showColumns ($ tb); foreach (array) $ fields as $ k => $ v) {if ($ v ['primary']) {$ _ pk_array [$ tb] = $ k; break ;}}$ this-> fields =$ _ pk_array; F ('_ pK', $ _ pk_array, 'cache/fields');} return $ this-> fields [$ table];}