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

Add sqlite support #1770

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

rudolfschmidt
Copy link

I wanted to contribute with an SQL dialect for the project. I have tested it on my system and it works.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 14, 2024
@mp911de mp911de added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Apr 15, 2024
Copy link
Member

@mp911de mp911de left a comment

Choose a reason for hiding this comment

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

Thanks for your suggestion. It would make sense to include an additional dialect. Can you also include the JDBC driver changes necessary in pom.xml? We can look into test cases.

@mp911de mp911de changed the title add sqlite support Add sqlite support Apr 18, 2024
@mp911de
Copy link
Member

mp911de commented Apr 18, 2024

We discussed this effort as a team and concluded two things:

  1. Right now, we're the sole maintainers of each contributed dialect including chasing for bugfixes and dialect-specific enhancements.
  2. We would like to find a model that allows community-driven dialect contribution in a way that enables developers to test their features against our test specifications. For this to happen, we need to rework our tests first.

Once the second item is addressed we can look for a way to integrate the dialect.

For the time being, if you keep the code on your project, you can use the DialectResolver extension mechanism to configure the JdbcDialectProvider extension point via spring.factories.

@mp911de mp911de added the status: on-hold We cannot start working on this issue yet label Apr 18, 2024
@benjamin-dreux
Copy link

Any update on the subject ?


@Override
public String getOffset(long offset) {
throw new UnsupportedOperationException("offset alone not supported");
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can do better, like LIMIT -1 OFFSET %d. According to official documentation it is fine to set LIMIT to the negative value.

}

@WritingConverter
private enum LocalDateTimeToNumericConverter implements Converter<LocalDateTime, Long> {
Copy link
Contributor

Choose a reason for hiding this comment

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

  1. We need to handle other JSR310 types as well.
  2. Can we safely assign UTC as a timezone to the LocalDateTime? I do not think so. I think we should not introduce the converters for LocalDate/LocalTime/LocalDateTime here, since we can cause bugs for users. It is better for them that the framework would not handle these types out of the box, rather than saving them assuming the UTC

@Override
public Collection<Object> getConverters() {
Collection<Object> converters = new ArrayList<>(super.getConverters());
converters.add(LocalDateTimeToNumericConverter.INSTANCE);

Choose a reason for hiding this comment

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

I didn't tried this dialect, but since sqlite, doesn't support boolean tye the same as everyone else, we should probably add a conversion for this too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: on-hold We cannot start working on this issue yet type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants