sharding-jdbc custom query (range query) case && pits that may be stepped on when querying

premise

Following the code of the previous sharding-jdbc dynamic insertion case by day, Sharding-JDBC, an artifact of sub-database and sub-table (case by day sub-table)_Tomorrow must.'s blog-CSDN blog_shardingsphere by day sub-tablehttps: //blog .csdn.net/wai_58934/article/details/125238850?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522166841466816782425123629%2522%252C%2522scm% 2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=166841466816782425123629&biz_id =0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~rank_v31_ecpm-1-125238850-null-null.nonecase&utm_term=sharding&spm=1018.2226.3001.4450

Some friends asked me. Then I re-examined my code and found that my solution is really rubbish (but it is applicable to some other scenarios, please depend on the scenario), because my business is to insert the data of the day into the table of the day, one table per day . I use a stupid sharding-jdbc for this. I use splicing sql (splicing the table name suffix according to the date, regardless of the splicing entered by the user ) to insert the data directly into the table. Then I refactored my mountain of shit code.

The following query is still: query by day score table, query by create_time field

text

The configuration (dependency and application.properties) is still the configuration shown in the previous sharding-jdbc. The difference is that one more RangeShardingAlgorithm is implemented in the DateAlgorithm class (customized class) that specifies the table-splitting algorithm strategy to rewrite doSharding to perform range queries and return the set of tables to be queried.

    @Override
    public Collection<String> doSharding(Collection<String> collection, RangeShardingValue<String> rangeShardingValue) {
        // 拿到范围
        Range<String> range = rangeShardingValue.getValueRange();
        String lowerEndpoint = range.lowerEndpoint();
        String upperEndpoint = range.upperEndpoint();
        ArrayList<String> list = new ArrayList<>();
        long betweendays = betweendays(lowerEndpoint, upperEndpoint);
        // 算出需要查询哪些表
        yesterday(new SimpleDateFormat("yyyy-MM-dd").parse(range.upperEndpoint()).getTime(),betweendays,list);
        return list;
    }
    public void yesterday(long date, long times, Collection<String> collection){
        DateFormat dateFormat=new SimpleDateFormat("yyyyMMdd");
        Calendar calendar = Calendar.getInstance();
        // 设置指定日期,月份需要减一
        calendar.setTime(new Date(date));
        String yesterdayDate=dateFormat.format(calendar.getTime());
        collection.add(logicTableName+yesterdayDate);
        calendar.set(Calendar.HOUR_OF_DAY,-24);
        if(times>0){
            times = times - 1;
            yesterday(calendar.getTimeInMillis(),times,collection);
        }
    }
    public long betweendays(String start,String end) throws Exception {
        //设置转换的日期格式
        SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
        //开始时间
        Date startDate = sdf.parse(start);
        //结束时间
        Date endDate = sdf.parse(end);
        //得到相差的天数 betweenDate
        return (endDate.getTime() - startDate.getTime())/(60*60*24*1000);
    }

 The above calculation code can be optimized, and I leave it to you!

At this point, we have finished writing the logic of the custom routing table. We just need to use it like this. Note that there must be a sharding-column condition, in this case the create_time field

        QueryWrapper<Communication> wrapper = new QueryWrapper<>();
        wrapper.between("create_time",start,end);
        List<Communication> list;
        list = mapper.selectList(wrapper);

Pots that may be stepped on when using

Do not use the @Param("xxx") annotation in the input parameter of mapper_sql written by yourself. Otherwise, sharding-jdbc will fail to recognize the input parameters.

Guess you like

Origin blog.csdn.net/wai_58934/article/details/127850201
Recommended