|
|
|
| QQ群(86020680) | 微信群 | 过期请联系管理员 |
| regardless of bugs, doubts, requirements, source code, competitors any questions, please contact skype: server@anyline.org |
||
The core of AnyLine is a runtime-oriented dynamic metadata mapping system that is compatible with over 100 relational and non-relational databases.
It is often used as the underlying support for dynamic structure scenarios, appearing as an SQL parsing engine or adapter.
【Document】
【Quick Start】
【Applicable Scenarios】
【Architecture Diagram】
Relying on a dialect conversion engine and metadata mapping library synthesized by built-in rules and external plugins,
we aim to establish a universal standard across databases on this foundation, enabling unified operations on heterogeneous databases.
AnyLine MDM focuses on runtime metadata dynamic mapping, primarily used for operating database structures, reading/writing metadata, and providing underlying support for dynamic scenarios. It often acts as an SQL synthesis engine or adapter in contexts such as:
- Data middle platforms
- Visualized data sources
- Low-code platforms
- SaaS applications
- Custom forms
- Heterogeneous database migration and synchronization
- IoT/vehicle network data processing
- Dynamic forms and query conditions
- Web crawler data parsing
- Supports runtime dynamic registration, switching, and deregistration of various data sources.
- Provides 7 data source registration methods and 3 switching mechanisms.
- Supports dynamic management of database structures (e.g., automatic table creation, field extension).
- Standardizes metadata collection (data types, comments, constraint rules) for unified governance of data structures and metadata.
- Enables table structure difference comparison, heterogeneous database structure replication, and data synchronization.
- Generates cross-database dynamic DDL by comparing metadata, analyzing table structure differences.
- Supports field type mapping, constraint conversion, indexing, etc., commonly used in database migration and version synchronization.
- Provides metadata-driven dynamic query solutions for flexible data filtering, sorting, and pagination.
- Supports multi-layer complex condition combinations and cross-database compatibility.
- Automatically generates query conditions in formats like JSON, String, or ConfigStore, ideal for low-code platforms to avoid cumbersome judgments, traversals, and format conversions while maintaining high performance and maintainability.
- Unifies database dialects for seamless metadata object compatibility across databases (relational, key-value, time-series, graph, document, columnar, vector, search, spatial, RDF, Event Store, Multivalue, Object).
- Specifically supports domestic databases.
- Based on a dynamic expression engine and SQL-like filtering, with built-in mathematical formulas, enables one-click aggregation, filtering, pivoting, and other operations on result sets, avoiding cumbersome ORM traversal.
- Supports arbitrary data source switching while maintaining multiple transaction states and cross-thread transactions.
- Manages roles, users, and permissions.
-
AnyLine: Designed for highly dynamic runtime scenarios, natively supporting runtime uncertainties.
- Handles dynamic data source access requests with heterogeneous structures and protocols.
- Adapts to real-time changes in metadata (e.g., table structures, field definitions).
- Provides dynamic model reconstruction and query adaptation through metadata management and adaptive mapping.
-
Traditional ORM: Suited for static or relatively stable business scenarios.
- Relies on predefined database structures and entity relationships during development.
- Ensures system stability with upfront modeling and design.
-
AnyLine: Targets middleware development platforms for building low-code platforms, dynamic query engines, etc.
- Empowers end-users to create customized business applications via visual configuration (e.g., dynamic reports, data analysis views).
-
Traditional ORM: Used for developing end-user business systems (e.g., ERP, CRM, OA).
- Maps database tables to object models for object-oriented database operations.
-
AnyLine: Metadata-driven, abstracting data structures and business logic.
- Allows dynamic configuration of data models and business rules during early project stages.
- Adapts to changing business requirements without a complete object model.
-
Traditional ORM: Operates on entity classes directly mapped to database tables.
- Maps tables to programming language classes, with fields and relationships reflected as class properties and associations.
-
AnyLine: For system architects and framework developers building highly flexible, extensible systems.
- Provides runtime data structure and business rule definition capabilities.
- Addresses system reconfiguration challenges due to requirement changes.
-
Traditional ORM: For application developers building relational database-backed systems.
- Simplifies database access and improves development efficiency.
-
AnyLine: Requires deeper technical expertise, especially in metadata-driven development and dynamic system design.
- Users must understand dynamic data model design and translate business requirements into configurable metadata rules.
-
Traditional ORM: Easier to learn and use, lowering the database operation threshold for developers.
| Aspect | AnyLine | Traditional ORM (e.g., Hibernate) |
|---|---|---|
| Dynamic vs Static | Runtime metadata-driven, supports dynamic data source registration. | Relies on static entity class and database table pre-mapping. |
| Metadata vs Object | Operates on database structures (tables, views, columns) and metadata. | Operates indirectly via object models (classes/properties). |
| Multi-Database | Adapts dynamically via metadata engine and SQL dialect conversion. | Requires hardcoded entity classes and dialect configuration. |
| Dimension | AnyLine (DataSet/DataRow) | Traditional ORM (Entity Class) |
|---|---|---|
| Data Representation | Dynamic structure (DataRow = row, DataSet = table). | Static strongly-typed classes (e.g., User.java). |
| Flexibility | Adapts to table structure changes dynamically. | Requires code changes for table structure modifications. |
| Query Result Handling | Directly operates on dynamic result sets. | Requires DTOs or projection interfaces. |
| Low-Code Support | Suitable for dynamic forms and ad-hoc queries. | Requires predefined entity classes. |
| Performance Overhead | Lightweight, no reflection/proxy generation. | May incur overhead due to reflection/bytecode enhancement. |
| Complex Mapping | Manual handling by default (e.g., multi-table JOIN results). | Automatically manages associations (e.g., @OneToMany). |
| Use Cases | Dynamic business scenarios, heterogeneous databases. | Fixed business models (e.g., ERP, CRM). |
- Parsing Layer: Automatically converts standard SQL syntax into database-specific dialects.
- Metadata Abstraction Layer: Builds a unified data view to shield structural differences.
- Multi-Protocol Adaptation Layer: Supports mixed protocols (JDBC/ODBC/REST) for seamless heterogeneous data source access.
- DataSourceHolder: Manages dynamic data sources.
- DataRuntime: Context environment associating data sources, adapters, connection pools, and services.
- DriverAdapter: Generates commands,屏蔽ing database command differences and data type compatibility.
- DriverActuator: Executes commands.
- ServiceProxy: Manages service-level data source switching.
- DataSet/DataRow: Encapsulates data, performs in-memory computation, and format conversion.
- Runtime Dynamic Data Source and Structure Support: Dynamically register/switch data sources and generate SQL for complex queries based on metadata.
- Simplified Database Operations: Provides concise APIs for pagination, CRUD operations, and dynamic query conditions.
- Flexible Result Set Processing: Processes result sets as
Maptypes with rich data processing functions (null handling, string manipulation, math calculations). - Multi-Data Source Support: Manages multiple data sources via simple APIs, enabling focus on business logic.
- Reduced Repetitive Work: Supports user-defined query conditions via configuration dictionaries or low-code platforms.
- Multi-Dialect Support: Supports DML/DDL operations across databases (including domestic and niche databases), reducing syntax familiarity requirements.
- Improved Development Efficiency: Simplifies database operations and auto-generates SQL, reducing manual effort and errors.
- Enhanced Flexibility: Supports dynamic data sources, structures, and result set processing for diverse needs.
- Lower Development Difficulty: Provides simple APIs and rich functions, eliminating the need to master hundreds of database syntaxes.
- Flexibility: Adapts to runtime requirements with dynamic data sources and structures.
- Efficiency: Simplifies workflows and auto-generates SQL for faster development.
- Ease of Use: Offers concise APIs and rich functions, lowering the learning curve.
Of course, we are not abandoning Entity or ORM. Different scenarios indeed require different solutions, and the design philosophy of AnyLine is precisely to provide flexibility and extensibility without excluding the use of traditional Entity or ORM.
- Entity/ORM has advantages such as strong typing, compile-time checking, and high code readability in predictable and fixed scenarios. It is suitable for scenarios with stable business logic and well-defined data structures.
- AnyLine focuses on dynamic and runtime scenarios, such as data middle platforms, multiple data sources, dynamic query conditions, and flexible result set processing, addressing the shortcomings of traditional ORM in these scenarios.
- If the business logic is clear and the data structure is fixed (e.g., order systems, user management), using Entity/ORM is a more suitable choice.
- If the business logic is complex and the data sources change dynamically (e.g., data middle platforms, reporting systems, multi-tenant systems), the dynamic capabilities of AnyLine can significantly improve development efficiency.
- The source code of AnyLine indeed uses multiple Entities (such as geometric shapes), which shows that AnyLine itself does not exclude Entities but chooses the most appropriate tool based on the scenario.
- In AnyLine, Entities can serve as carriers of fixed data structures, combined with dynamic data sources and query conditions to achieve more flexible business logic.
- Programmers need to have the ability to differentiate scenarios and choose appropriate technical solutions based on business requirements.
- For fixed scenarios, prioritize the use of Entity/ORM; for dynamic scenarios, prioritize the use of AnyLine.
- In actual projects, Entity/ORM and AnyLine can be used in combination to leverage their respective advantages.
- For example, use Entity/ORM to handle core business logic and AnyLine to handle dynamic queries, multiple data source switching, and other requirements.
- Do not force-fit scenarios just to use a certain technology; choose the simplest solution based on actual requirements.
- The goal of AnyLine is to reduce development complexity, not increase it.
Note that the data source here is not a master-slave relationship, but multiple completely unrelated data sources.
DataSource ds_sso = new DruidDataSource();
ds_sso.setUrl("jdbc:mysql://localhost:3306/sso");
ds_sso.setDriverClassName("com.mysql.cj.jdbc.Driver");
...
DataSourceHolder.reg("ds_sso", ds_sso);
OR
DataSourceHolder.reg("ds_sso", pool, driver, url, user, password);
DataSourceHolder.reg("ds_sso", Map<String, Object> params); //Corresponding properties of the connection pool k-v
//Query the SSO_USER table of the ds_Sso data source
DataSet set = ServiceProxy.service("ds_sso").querys("SSO_USER");From static configuration file data source (if it is a Spring environment, it can be in Spring format)
#Default Data Source
anyline.datasource.type=com.zaxxer.hikari.HikariDataSource
anyline.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
anyline.datasource.url=jdbc:mysql://localhost:33306/simple
anyline.datasource.user-name=root
... more parameters
#Other data sources
anyline.datasource-list=crm,erp,sso,mg
anyline.datasource.crm.driver-class-name=com.mysql.cj.jdbc.Driver
anyline.datasource.crm.url=jdbc:mysql://localhost:33306/simple_crm
anyline.datasource.crm.username=root
anyline.datasource.erp.driver-class-name=com.mysql.cj.jdbc.Driver
anyline.datasource.erp.url=jdbc:mysql://localhost:33306/simple_erp
anyline.datasource.erp.username=rootDML
// If it is a web environment
service.querys("SSO_USER",
condition(true, "NAME:%name%", "TYPE:[type]", "[CODES]:code"));
//true Indicates the need for pagination, and conditions without parameter values are ignored by default
//SQL:
SELECT *
FROM SSO_USER
WHERE 1=1
AND NAME LIKE '%?%'
AND TYPE IN(?,?,?)
AND FIND_IN_SET(?, CODES)
LIMIT 5,10 //Generate different SQL statements based on specific database type
CEB7
s
//User defined query conditions, low code scenarios generally require more complex query conditions
ConfigStore configs;
service.query("SSO_USER", configs);
//ConfigStore provides all SQL operations
//Sample code and instructions for SQL parameters for multi table, batch submission, custom SQL, and parsing XML definitionsRead and write metadata
@Autowired("anyline.service")
AnylineService service;
//Query the SSO_USER table structure of the default data source
Table table = serivce.metadata().table("SSO_USER");
LinkedHashMap<String, Column> columns = table.getColumns(); //columns of Table
LinkedHashMap<String, Constraint> constraints = table.getConstraints(); //constraints of table
List<String> ddls = table.getDdls(); //ddl for create table
//drop table and recreate
service.ddl().drop(table);
table = new Table("SSO_USER");
//The data type here is arbitrary, regardless of whether it is int8 or bigint, it will be converted to the correct type during execution
table.addColumn("ID", "BIGINT").autoIncrement(true).setPrimary(true).setComment("primary key");
table.addColumn("CODE", "VARCHAR(20)").setComment("code of user");
table.addColumn("NAME", "VARCHAR(20)").setComment("full name");
table.addColumn("AGE", "INT").setComment("age of user");
service.ddl().create(table);
//or service.ddl().save(table); //During execution, it will distinguish which columns need to be added and which columns need to be alteredDatabase transactions
//Because the method can switch data sources multiple times at any time, the annotation can no longer capture the current data source
//More transaction parameters can be obtained through the TransactionDefine parameter
TransactionState state = TransactionProxy.start("ds_sso");
//Operational data(insert update delete)
TransactionProxy.commit(state);
TransactionProxy.rollback(state);
TeraData
Presto
OpenSearch
OpenEdge
ChinaMobileDB
ChinaUnicomDB
LightDB
Pinecone
Phoenix
Nebula
JanusGraph
Db4o
Sedna
PlanetScale
Infobright
ObjectStore
mSQL
Giraph
GTM
Hibari
ObjectDB
TDSQL(腾讯云计算（北京）有限责任公司)
MaxCompute
AnalyticDBMySQL
GraphEngine
BoltDB
LokiJS
Redland
SpliceMachine
AnalyticDBPostgreSQL
ModeShape
Elliptics
Elassandra
ApsaraDBPolarDB
FlockDB
NEventStore
Comdb2
ComputeDB
TinkerGraph
Table_Store
Badger
MyScale
HyperLevelDB
SenseiDB
TSDB
TerarkDB
OrigoDB
Siaqodb
Upscaledb
Acebase
ArgoDB
SWCDB
BergDB
DaggerDB
HGraphDB
RaptorDB
Rizhiyi
Crase
