dayatang / dddlib Goto Github PK

你好，由于我们有个遗留项目采用了dddlib的3.5版本，近期需要重启该项目。我在分支和标签里面都找不到3.5这个版本。请问我要怎么找到3.5的代码或者现有的仓库？

请问有计划支持mybatis

Entities and the Repository API should not dictate which persistence method is used under the covers.

EntityRepository怎么实现可以分页和返回记录的总条数

Your project uses some dependencies with CVEs. I found that the buggy methods of the CVEs are in the program execution path of your project, which makes your project at risk. I have suggested some version updates. Here is the detailed information:

• Vulnerable Dependency: mysql : mysql-connector-java : 5.1.35

• Call Chain to Buggy Methods:

  • Some files in your project call the library method com.mysql.jdbc.NonRegisteringDriver.connect(java.lang.String,java.util.Properties), which can reach the buggy method of CVE-2017-3586.

    • Files in your project:
      dddlib-datasource-router/src/main/java/org/dayatang/mysql/jdbc/GeminiReplicationConnection.java
    • One of the possible call chain:

    com.mysql.jdbc.NonRegisteringDriver.connect(java.lang.String,java.util.Properties)
    com.mysql.jdbc.ConnectionImpl.getInstance(java.lang.String,int,java.util.Properties,java.lang.String,java.lang.String)
    com.mysql.jdbc.ConnectionImpl.<init>(java.lang.String,int,java.util.Properties,java.lang.String,java.lang.String)
    com.mysql.jdbc.ConnectionImpl.createNewIO(boolean)
    com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(boolean,java.util.Properties)
    com.mysql.jdbc.ConnectionImpl.coreConnect(java.util.Properties)
    com.mysql.jdbc.MysqlIO.doHandshake(java.lang.String,java.lang.String,java.lang.String)
    com.mysql.jdbc.MysqlIO.negotiateSSLConnection(java.lang.String,java.lang.String,java.lang.String,int)
    com.mysql.jdbc.ExportControlled.transformSocketToSSLSocket(com.mysql.jdbc.MysqlIO)
    com.mysql.jdbc.ExportControlled.getSSLSocketFactoryDefaultOrConfigured(com.mysql.jdbc.MysqlIO) [buggy method]
    

• Update suggestion: version 8.0.19
  8.0.19 is a safe version without CVEs. From 5.1.35 to 8.0.19, 6 of the APIs (called by 10 times in your project) were removed.

AbstractEntity作为DDD的基类,在使用时我发现了的几个问题:

1. 如果我的的ID不是LONG类型, 无法扩展修改
2. 如果我的继承策略是TABLE_PER_CLASS, 则会报异常: "Cannot use identity column key generation with mapping for". 原因是由于ID的生成策略被设置为AUTO, TABLE_PER_CLASS继承策略不允许. 但由于注解的位置在字段,所以无法override该ID的生成策略.
3. 第二个问题可以通过继承id getter setter并abstract，再通过具体类在getter上override id的生成策略
4. 实际使用时会由于多态、重写方法的注解，会使注解的位置混乱，可能导致的未知问题。hibernate推荐把注解统一写在getter上。