gfakbar20 commented on PR #1990: URL: https://github.com/apache/polaris/pull/1990#issuecomment-3057887031
> I’m open to relocating the converters if needed, but could you clarify the concern around placing converters within business object classes? just a pragmatic one, and the current usage is inside the polaris service common module since I'm not so sure about the source code progression. But placing it in the public api model module sounds good to me because of the clearer separation and better module ownership. > Also, when you mentioned circular dependencies, are we talking about actual runtime dependency issues or something specific to Gradle module boundaries? If it's not about Gradle, what kind of circular dependency are we concerned about here? it tends toward runtime dependency because the service implementation is injected by quarkus. For example, I will use create catalog as an example. The flow will be as follows: * Catalog is used as an implicit parameter in `PolarisCatalog.createCatalog` method. * `PolarisCatalog.createCatalog` calls `PolarisCatalogApiService.createCatalog` using the same object class which will be implemented by `PolarisServiceImpl.createCatalog`. * 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`). 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. -- 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
