flyrain commented on PR #1990: URL: https://github.com/apache/polaris/pull/1990#issuecomment-3064769793
> But placing it in the public api model module sounds good to me because of the clearer separation and better module ownership. Placing the converter in the api model module will make a more stable module(API model) depends on a less stable one(Polaris core). I think that's an anti-pattern we will need to avoid. > Inside PolarisServiceImpl.createCatalog, the converter method inside CatalogEntity will transform an object from or to between Api payload schema (Catalog) and the business model (CatalogEntity). I’m not quite following why this is considered a circular dependency, could you elaborate? The converter is simply responsible for transforming between a business object and an API model, and it fits naturally within the module where the business object resides. I do agree with @eric-maynard that centralizing model converters could be a good idea for maintainability and consistency. But that feels like a design choice, not something related to circular dependency. > Well it is nice to know that the API will be stable, but is the openApi generator also stable enough to be updated by the dependabot? I only worked with openApi generator shortly 2 years ago to notice any detrimental(breaking) changes to my project when the version is upgraded. I don’t think the OpenAPI generator should be a concern in this case. Regardless of how it's generated, API models are fundamentally more stable than business or persistence entities. Even in the worst-case scenario, we could always fall back to manually adding the API models. -- 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: issues-unsubscr...@polaris.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
