terrymanu commented on issue #34944:
URL:
https://github.com/apache/shardingsphere/issues/34944#issuecomment-3506385937
Thank you for your suggestion regarding the OpenGauss module architecture. I
have conducted a thorough analysis of the current implementation, and here are
the detailed findings:
Current Technical Dependencies
Indeed, the OpenGauss module depends on the PostgreSQL module:
<!-- opengauss/pom.xml -->
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>shardingsphere-database-connector-postgresql</artifactId>
<version>${project.version}</version>
</dependency>
Technical Reasons for This Dependency
This dependency design has technical justifications:
1. Technical Lineage: OpenGauss is based on PostgreSQL and shares many
system table structures and SQL syntax
2. Code Reuse: OpenGaussMetaDataLoader and PostgreSQLMetaDataLoader use
almost identical metadata query SQL
3. Maintenance Efficiency: Avoids maintaining two sets of similar code,
following the DRY principle
OpenGauss Uniqueness
Despite the dependency, OpenGauss does have its own unique implementations:
- Transaction option differences: OpenGauss supports distributed
transactions while PostgreSQL does not
- Proprietary system views: Such as gs_auditing, gs_wlm_session_info, and
other OpenGauss-specific features
- Different data type handling options
Recommended Approach
Based on the current situation, I recommend:
Maintain the current architecture for the following reasons:
1. Technical Soundness: The current architecture aligns with the technical
relationship between OpenGauss and PostgreSQL
2. Unclear Benefits: The benefits of complete separation are unclear, but
it would significantly increase development and maintenance costs
3. Gradual Improvement: If OpenGauss develops more differentiated features
in the future, we can consider refactoring then
Additional Information Needed
If the project team believes better independence is necessary, we would
appreciate more specific background information:
1. Specific Pain Points: What specific problems have you encountered with
the current dependency in actual usage?
2. Feature Limitations: Which OpenGauss-specific features cannot be well
supported due to PostgreSQL dependencies?
3. Version Compatibility: Are there compatibility issues caused by version
differences between OpenGauss and PostgreSQL?
4. Performance Impact: Does the current dependency have a negative impact
on OpenGauss performance?
Conclusion
This issue raises a valuable architectural question. However, based on
current technical realities, I recommend maintaining the existing design for
now. If OpenGauss indeed develops enough differentiated features in the
future, or if the community provides specific feedback about maintenance
pain points, we can consider architectural refactoring then.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
