Recently, a project team of the company wants to split the previous single application into services. The ID primary key of the table is generated by default snowflake algorithm of Mybatis Plus.

Quick off work of time, small partner ran to look for me, : “quick give me a look at this problem, card this card small along while!” . Pull and drag, coax and cheat to pull me to his computer. In my opinion, this young friend is not a great skill, but he is very rich in experience. The problem that he was stuck for a long time should not be a small problem. If I could not deal with it for a while, it really delayed my work, so I was reluctant to sit down in his place.

First, the phenomenon is like this

Id BigINT is the primary key of the table, used to store the id generated by the snowflake algorithm, well, this has no problem!

CREATE TABLE user (id BIGINT(20) NOT NULL COMMENT 'iD ', # delete);Copy the code

Use the Long type for database ID data. Well, there’s no problem, the Snowflake algorithm just generates a string of numbers, and Long is the standard answer!

@Data public class User { private Long id; // Other member variables are omittedCopy the code

Break point on the back end. See data response as JSON response to the front end, ok

{id: 1297873308628307970, // other attributes omitted}Copy the code

Finally, this data is returned to the front end, which receives it, modifies it, and the back end receives it again. There is a strange problem: the id returned from the back end is 12978733086283000000 instead of 1297873308628307970

Second, analyze the problem

My first feeling was that the developer had mixed up the data and put the object ID of XXX on the OBJECT ID of YYY. So, we followed the code from front end to back end and back end to front end.

There is nothing wrong with the logic of the code. At this time, I was a little irritable, really delay my work! But there was no turning back. Since I sat down, I had to help him solve it. Otherwise, how would this team take it? Thinking of this, I calmed down and began to think.

1297873308628300000 - > 1297873308628307970Copy the code

These two numbers look similar. They seem to have been rounded. At this time the head came out of an idea, is the accuracy lost? Where can accuracy be lost?

  • Server ids are of type Long and cannot be lost
  • What kind of front end is it, JSON string to JS object, and number to receive Long

Number is 16 bits (snowflake ID is 19 bits), So: the accuracy of JS Number data type is lost. The problem is finding it! Small partners cast admiring eyes, 5 minutes to find this problem. But what good would it do? Gotta fix it!

Third, solve the problem

I’ll change the id field of all database tables from Long to String. I asked him how many tables do you have? He said more than 100.

  • More than 100 tables and more than 100 entity classes need to be changed
  • There are also various Service layers that use entity classes to change
  • The Controller layer should be changed after Service is changed
  • The point is that String and Long are both common types, and he is afraid to replace them in batches

The young friend picked up the phone to order dinner, saying that it was inevitable to work overtime tonight. I’d like to say: you’d better not change, String do ID query performance will decline, I think again! There is A loss of precision between back-end A and front-end B, so either change the front-end, or change the back-end, or… . “Ah ah, you wait first don’t order food, back end A to front end B you do with what serialization?” My friend told me that Jackson was used, which is easy. Jackson is familiar to me.

Back end ID(Long) ==> Jackson(Long to String) ==> Front end use String ID, front end use JS String precision will not be lost. So when the front-end sends a String of 19 digits back to the server, can it use a Long to receive it? Sure, this is how Spring deserialization parameters receive default support.

The final solution is: the front end uses the type of String snowflake ID to maintain accuracy, the back end and the database continue to use the type of Long(BigINT) does not affect the database query execution efficiency.

The remaining problem is how to convert the Long ID into a String response when using Jackson for JSON serialization in Spring Boot applications. The scheme is as follows:

@Configuration public class JacksonConfig { @Bean @Primary @ConditionalOnMissingBean(ObjectMapper.class) public ObjectMapper jacksonObjectMapper(Jackson2ObjectMapperBuilder builder) { ObjectMapper objectMapper = builder.createXmlMapper(false).build(); SimpleModule SimpleModule = new SimpleModule(); //JSON Long ==> String simpleModule.addSerializer(Long.class, ToStringSerializer.instance); objectMapper.registerModule(simpleModule); return objectMapper; }}Copy the code

The little friend put down the phone and cast an admiring glance again. “Let’s go and get off work together!” I said to my partner, my partner asked me all the way how do you learn? I said something grand about wanting to learn and asking. In fact, I was thinking: I’m a lazy person, but I can’t say. Can lie down never sit, can automatic never manual, can taxi never drive. Getting things right the first time is the way to save time and effort! So many years of “laziness”, decided that I need to think about more “shortcut”, thinking about the process of “shortcut” is the secret of my continuous progress! Diligent people are the productive forces of society, and lazy people are the creativity of society!

Welcome to my blog, where there are many fine collections

  • This article is reprinted with a credit (must be accompanied by a link, not only the text) : Antetokounmpo blog.

Feel helpful to you, help me like, share! Your support is my inexhaustible creative power! . In addition, the author recently a period of time output as follows boutique content, looking forward to your attention.

  • Spring Boot2.0 by Hand
  • Spring Security- JWT-OAUTH2
  • RBAC Authority Management System for Actual Combat Front-end and Back-end Separation
  • “Actual SpringCloud Micro-service from Bronze to King”
  • VUE Series