Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SQL Criteria Implementation #1394

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

gtnicol
Copy link

@gtnicol gtnicol commented Aug 17, 2022

Initial SQL implementation of Criteria API limited to basic CRUD.

Initial SQL implementation of Criteria API limited to basic CRUD.
@elucash
Copy link
Member

elucash commented Sep 1, 2022

I'm sorry for delay, needed time to look around the implementation. As usual with such big contributions, it's a difficult task, all or nothing, either just take all or nitpick / fight for many significant or insignificant details to no end, which require so much time that we probably don't have. I actually want us to merge it. Here's my points:

  • Need to add to readme file notes (or add more notes) about the experimental nature of this implementation, that it's a subject to change (API or impl, or both) and all the "caveat emptor" stuff.
  • I would ask to review dependencies (such as some jackson modules) to be marked <optional>true or <scope>provided if they can be made so, i.e. if they are not absolutely necessary.
  • In general, I'm not comfortable with the way reflection is used for some model discovery and how Jackson marshaling is integrated. But because we don't have good standard approaches for these, we'll let it fly as it is. I've used some experimental stuff in another project which reads SQL datasets into immutable objects, but that approach also use quite experimental generated Datatypes and likewise experimental Codec runtime bridges (with JSON delegated to Moshi/ok-io), so I cannot recommend that approach right now (if curious, you can look into https://github.com/immutables/io/blob/master/io/regres/src/io/immutables/regres/Coding.java and other classes around in that repo). So let it be, given that we'll mark experimental nature of this implementation.
  • Please adjust the formatting the Java files in this PR, basically you can use Google Java code conventions or at least something like this .editorconfig (It's our bad that we don't have formatter or this editor config file attached, we'll fix this eventually)
[*]
indent_style = space
indent_size = 2
continuation_indent_size = 4
max_line_length = 120
charset = utf-8
end_of_line = lf
insert_final_newline = true

Having these thoughts, I'll also will kindly summon the quick view of @asereda-gs in case there are more ideas / considerations (especially on the model discovery/reflection in case there are some better routines).
And I think we will be able to merge this. Thank you!

@gtnicol
Copy link
Author

gtnicol commented Sep 2, 2022

Cool. I'll wait for any further comments then make the changes and commit. FWIW. I also dislike the reflection... I was wondering if we shouldn't have something that generates marshaling code, much like the Gson TypeAdapter code? Given the experimental nature of this, maybe that'd be overkill at this point.

@asereda-gs
Copy link
Member

Hello,

Thanks for this PR. Please give me some time to review it.

@gtnicol
Copy link
Author

gtnicol commented Sep 7, 2022

Sure thing. Thanks!

/**
* Implementation of {@code Backend} which delegates to the underlying SQL specific commands.
*/
public class SQLBackend implements Backend {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is SQLBackend duplicated? diff shows SQLBackend.java and SqlBackend.java

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a rename... case change.

@gtnicol
Copy link
Author

gtnicol commented Sep 23, 2022

Hello,

Thanks for this PR. Please give me some time to review it.

Andrei, any ETA on review? I can do some work on this over the weekend.

@elucash
Copy link
Member

elucash commented Oct 4, 2022

Sorry for the waiting. I was lucky to be almost at the center of the IAN landfall so just slowly getting back to business. It seems that @asereda-gs have no easy reservations (only deep ones, which might require in-depth investigation) I'll merge it as soon as I will get better internet, granted we fix minor stuff and highlight the experimental nature of the PR

@gtnicol
Copy link
Author

gtnicol commented Oct 4, 2022

Cool. I'll clean up the formatting and might also clean up some of the reflection. Give me a few days to turn it around.

@elucash
Copy link
Member

elucash commented Oct 4, 2022

Thank you! JIC in general we would prefer SqlSomething, not SQLSomething. It's rooted in Google Java conventions, some other conventions (like Google's Go lang etc) could prefer other styles.

@elucash
Copy link
Member

elucash commented Oct 18, 2022

Internet is still slow (mobile internet, broadband is not restored yet). The next release will be only after I'll have good connection. But I can merge this, please remind be if anything is remaining here (style issues?). Hope to merge this promptly, thank you!

@jmoghisi
Copy link
Contributor

Hi @elucash , hope you are well and recovered from the storm. What's the latest on this PR? May it be merged?

@elucash
Copy link
Member

elucash commented Nov 14, 2022

Hi @jmoghisi I think I can merge this. Just don't want to reformat/codestyle after merge, so maybe those things can be included (cc @gtnicol).
Basically, reformat according to

indent_style = space
indent_size = 2
continuation_indent_size = 4

Rename prefixes SQL* -> Sql*

Can we remove SQL migration library and test-migrations.xml file? For tests, simple plain SQL script will work. Just createStatement and read file (getResourceAsStream)

@gtnicol
Copy link
Author

gtnicol commented Nov 14, 2022 via email

@gtnicol
Copy link
Author

gtnicol commented Nov 14, 2022

Why would @Generator.Template public class Sql extends AbstractTemplate {} not result in Sql.generator being called to generate the code? I was mirroring what is in samplegenerators where you can see the output in target

@gtnicol
Copy link
Author

gtnicol commented Nov 14, 2022

I figured it out. I will do the RowMapper generation and then do another checkin.

@gtnicol
Copy link
Author

gtnicol commented Nov 25, 2022

I just checked in a pretty significant update which removed the Jackson and Liquibase dependencies. It now uses the generator framework to generate a default setup and a default row mapper (these can be overridden). I also renamed a lot of the files and reformatted everything.

@elucash
Copy link
Member

elucash commented Nov 25, 2022

Thank you for update! As I've recently got my broadband internet connection restored, planning to do the long awaited maintenance release over the weekend. Let me know if you think the PR is feature complete for final review and merge or we can have some more time and include it in the release soon after.

@gtnicol
Copy link
Author

gtnicol commented Nov 25, 2022

The one major area I can see potential issues is that it generates a RowMapper which calls the builder - so it assumes a Value.Immutable annotation and doesn't take Style into account. That said, it should be pretty much ready to go - I ran a few more tests and assuming you think this is OK, I'd say it's good enough.

@elucash
Copy link
Member

elucash commented Dec 13, 2022

i'm doing an 2.9.3 release now, not including this, but expect this to be merged soon after. I'm assuming you're saying it's ready enough (given an uncertainty with some issues).

@gtnicol
Copy link
Author

gtnicol commented Dec 13, 2022

Looks like we need to change the dependency to 2.9.3 from 2.9.3-SNAPSHOT? Apart from that I'd say we can merge it in - the code generation path vs reflection cleans things up a lot.

@gtnicol
Copy link
Author

gtnicol commented Dec 25, 2022

This should be OK to merge... all the tests and build run cleanly.

@gtnicol
Copy link
Author

gtnicol commented Jan 6, 2023

Anything blocking this from being merged at this point?

@elucash
Copy link
Member

elucash commented Jan 6, 2023

I'll merge it today, seems we don't have any resources/capacity for diving into any remaining details. As I've mentioned, we will just not advertise it as something stable, will stay experimental for a while etc.

@elucash
Copy link
Member

elucash commented Jan 6, 2023

@gtnicol just some build problems

[INFO] -------------------------------------------------------------
Error:  COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
Error:  /home/runner/work/immutables/immutables/criteria/sql/src/org/immutables/criteria/sql/commands/SqlCountCommand.java: Internal compiler error: java.util.ServiceConfigurationError: javax.annotation.processing.Processor: Provider org.immutables.generator.processor.Processor could not be instantiated at java.util.ServiceLoader.fail(ServiceLoader.java:232)
Error:  /home/runner/work/immutables/immutables/criteria/sql/src/org/immutables/criteria/sql/commands/SqlCountCommand.java:[35,14] The type SqlCountCommand is already defined

Let me know if it's something outside of this PR. Thank you for you patience

@gtnicol
Copy link
Author

gtnicol commented Jan 7, 2023

Looks like the SQL->Sql renaming didn't go through. I will build on Linux to make sure naming isn't an issue.

@gtnicol
Copy link
Author

gtnicol commented Jan 7, 2023

I have deleted the duplicate files and it builds cleanly under Ubuntu 22 now

Copy link
Member

@asereda-gs asereda-gs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @gtnicol!

Thank you for this PR and sorry that it takes so long for us to review it.

I have left small comments but think we should have a deeper discussion about SQL Backend for Criteria. Unfortunately it is not as straightforward as other backends (Mongo, Elastic etc.) since they already have POJO mapping / serialization "frameworks" included.

Probably several iterations will have to be done around POJO / ResultSet mapping and conversions.

I will continue looking and leaving comments.


import org.immutables.criteria.sql.conversion.RowMappers;

public class [_setup_class_name_] {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it necessary to generate special code for RowMapper ?

Isn't there enough type information using reflection ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's better without the reflection, no?

import org.immutables.criteria.expression.Query;
import org.immutables.criteria.sql.SqlSetup;
import org.immutables.criteria.sql.reflection.SqlTypeMetadata;
import org.junit.Test;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please use JUnit5.

pom.xml Outdated
@@ -107,8 +107,8 @@
<reactive-streams.version>1.0.2</reactive-streams.version>
<log4j2.version>2.17.1</log4j2.version>
<mongo-java-server.version>1.38.0</mongo-java-server.version>
<jackson.version>2.8.11</jackson.version>
<jackson-databind.version>2.8.11.6</jackson-databind.version>
<jackson.version>2.12.7</jackson.version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be version properties defined in main pom.xml.

Example: ${jackson.version}

import org.immutables.criteria.backend.JavaBeanNaming;
import org.immutables.criteria.expression.Path;

public class SqlPathNaming extends JavaBeanNaming {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case I would prefer composition (with a generic PathNaming interface) over inheritance.

Also I'm not sure JavaBeanNaming should be used at all.

*/
package org.immutables.criteria.sql.compiler;

public interface SqlExpression extends SqlNode {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please explain why do we need SqlExpression / SqlNode class hierarchy ?

import java.util.Map;
import java.util.stream.Collectors;

public interface SqlCommand {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this internal interface to sql criteria ? If so, can you please better comment it?

@elucash
Copy link
Member

elucash commented Jan 10, 2023

I think we will merge the initial version, given that it is experimental/unstable API and design should be changed around how result mappers and other field mapping works, maybe even aligning/ changing how other criteria backends are mapped, to use something common / general and flexible enough. I would as to address some of the stuff like testing framework usage. Maybe remove some intermediate speculative abstractions (see latest comments by @asereda-gs ) That could be done in this or a separate PR after this merged.
As of now there is build problem. It might again be something unrelated to this PR, but don't have energy to investigate it now, will return in 2-3 days.

Error:  Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project criteria-sql: Compilation failure
Error:  /home/runner/work/immutables/immutables/criteria/sql/src/org/immutables/criteria/sql/commands/SqlCountCommand.java: Internal compiler error: java.util.ServiceConfigurationError: javax.annotation.processing.Processor: Provider org.immutables.generator.processor.Processor could not be instantiated at java.util.ServiceLoader.fail(ServiceLoader.java:232)

@gtnicol
Copy link
Author

gtnicol commented Jan 10, 2023

let me have another look... I think getting rid of all the reflection stuff was a useful change

@gtnicol
Copy link
Author

gtnicol commented Feb 2, 2023

I have a feeling this is something else... it doesn't appear to be the code but something environmental or something with the tools.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants