Michael, What's your confluence id? For some reason, I can't add you using the email address.
Agree, that it's the right move to split the pull-request. Btw, keep the dev list in the copy, no need to exclude from the recipients' list. - Denis On Fri, Aug 14, 2020 at 1:10 PM Michael Pollind <mpoll...@gmail.com> wrote: > I created an account in confluence with mpoll...@gmail.com. > > I also took some time yesterday to split my work just for the ignite-core > and ignite-cache stuff: > https://github.com/micronaut-projects/micronaut-ignite/pull/33 > > This should be more approachable. > > On Fri, Aug 14, 2020 at 9:44 AM Denis Magda <dma...@apache.org> wrote: > >> Michael, welcome to the community! >> >> Igniters, let me introduce you to Michael, who is working on the Micronaut >> integration for Ignite >> <https://github.com/micronaut-projects/micronaut-ignite>. Even though >> the integration is hosted in the Micronaut repository, I thought it's in >> our interest to help Michael with the APIs design and support with other >> Ignite-specific challenges he might hit on the road. @Saikat Maitra, @Ilya >> Kasnacheev, @Valentin Kulichenko, I would appreciate if you folks get >> involved, at least, in the API design phase. >> >> Michael, answering your questions >> >> So I already have 2 implemented but I'm not really sure what you mean by >>> autostart for number 1? so at the moment I have the thin-client omitted >>> just for simplicity and I think it could just be added in afterwards. I'm >>> not sure how important it is in the whole scheme of things since this is my >>> first time really looking at ignite. we can start there and figure out >>> those details. >> >> >> Instead of the autostart, I was intended to say the autoconfigure >> feature, which is a Spring Boot term >> <https://apacheignite-mix.readme.io/docs/spring-boot#autoconfiguration-of-apache-ignite-servers-and-clients>. >> Sorry for the confusion. Anyway, that's when Micronaut automatically starts >> an Ignite client instance based on configuration settings. As you confirmed >> below, the integration logic already does this. >> >> When we design new public APIs, we frequently take advantage of Ignite >> Wiki by creating design documents that comprise an API interface with code >> samples showing how a developer is supposed to use the API. >> You tweak the APIs with code samples until those are settled. This >> approach helps to assess the APIs from the end-user standpoint and avoid >> common design mistakes before coding and releasing a feature for public >> usage. Furthermore, such design pages are an excellent source for a >> technical documentation that you create regardless. Check the "Key >> Interfaces" and "Examples" sections of the tracing feature's design page >> <https://cwiki.apache.org/confluence/display/IGNITE/IEP-48%3A+Tracing>. >> >> So, my suggestion to you would be as follows: >> >> - Create the Micronaut Integration page under the Design Documents >> tree >> <https://cwiki.apache.org/confluence/display/IGNITE/Design+Documents>. >> Sign up on the wiki and tell me your email/id. I'll grant you all the >> required editing permissions. >> - On that page, create a section for the autoconfigure feature by >> listing all possible configuration parameters the user can pass in YAML >> files and examples of how a client instance can be injected in application >> logic. Guess, thin and thick clients will be configured differently. >> - Another section should be related to the Micronaut Caching API. >> Again, public Ignite-specific APIs we're adding to Micronaut and how the >> user is supposed to use those. >> >> Once the page is ready, we'll start brainstorming on the APIs together >> using this discussion thread. >> >> 3 is giving me some problems since the SQL generated does not match up. >>> ignite rejected the query when I have auto generated fields in the DDL >>> statement and I've also dropped the scheme from the SQL and used the scheme >>> to resolve the target cache. I'm using SqlFieldsQuery to make the request >>> but there seems to be a few query options: >> >> >> If you'd like to carry on with this part of the integration, then I would >> start a separate discussion on the dev list. Or just put it off for a bit >> until we sort out the clients' configuration and Micronaut Caching APIs. >> >> - >> Denis >> >> >> On Thu, Aug 13, 2020 at 1:16 PM Michael Pollind <mpoll...@gmail.com> >> wrote: >> >>> Hello, >>> Denis Magda >>> >>> So I already have 2 implemented but I'm not really sure what you mean by >>> autostart for number 1? so at the moment I have the thin-client omitted >>> just for simplicity and I think it could just be added in afterwards. I'm >>> not sure how important it is in the whole scheme of things since this is my >>> first time really looking at ignite. we can start there and figure out >>> those details. >>> >>> here is the application.yml that i currently have for a basic >>> configuration. I'm using the bean definitions from spring to do this: >>> >>> ignite: >>> enabled: true >>> clients: >>> default: >>> path: classpath:standard.cfg >>> >>> >>> 3 is giving me some problems since the SQL generated does not match up. >>> ignite rejected the query when I have auto generated fields in the DDL >>> statement and I've also dropped the scheme from the SQL and used the scheme >>> to resolve the target cache. I'm using SqlFieldsQuery to make the request >>> but there seems to be a few query options: >>> >>> [image: image.png] >>> >>> >>> @IgniteRepository(value = "default", schema = "mydb") >>>> public interface UserRepository extends CrudRepository<User, Long> { >>>> } >>> >>> >>> so I created an account on the apache ignite forum: >>> http://apache-ignite-developers.2346864.n4.nabble.com/template/NamlServlet.jtp?macro=user_profile >>> >>> I wouldn't mind starting a thread to start planning out the API. >>> >>> From, >>> Michael Pollind >>> >>
