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 codec for LTREE type. #544

Merged
merged 5 commits into from
Jan 18, 2023
Merged

Add codec for LTREE type. #544

merged 5 commits into from
Jan 18, 2023

Conversation

cranst0n
Copy link
Contributor

@cranst0n cranst0n commented Sep 9, 2021

Adds a codec for the postgresql ltree type.

@tpolecat
Copy link
Member

tpolecat commented Sep 9, 2021

Cool! I will have a look.

@codecov-commenter
Copy link

codecov-commenter commented Sep 9, 2021

Codecov Report

Merging #544 (d0ff2f4) into main (1c24644) will increase coverage by 0.06%.
The diff coverage is 88.88%.

@@            Coverage Diff             @@
##             main     #544      +/-   ##
==========================================
+ Coverage   84.75%   84.81%   +0.06%     
==========================================
  Files         124      126       +2     
  Lines        1692     1719      +27     
  Branches      114      117       +3     
==========================================
+ Hits         1434     1458      +24     
- Misses        258      261       +3     
Impacted Files Coverage Δ
...odules/core/shared/src/main/scala/data/LTree.scala 86.95% <86.95%> (ø)
.../core/shared/src/main/scala/codec/LTreeCodec.scala 100.00% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Copy link
Member

@tpolecat tpolecat left a comment

Choose a reason for hiding this comment

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

A few comments. We also need to add it to the schema types doc page.

modules/core/shared/src/main/scala/data/LTree.scala Outdated Show resolved Hide resolved
modules/core/shared/src/main/scala/data/LTree.scala Outdated Show resolved Hide resolved
object LTree {
val Empty = LTree(Nil)

def unsafe(labels: String*): LTree = LTree(labels.toList)
Copy link
Member

Choose a reason for hiding this comment

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

Let's leave this out. The user can deal with the case where they're sure it's valid. We could also add a ltree"..." literal handler at some point.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can try to add a literal. I've never built one before but seems like the Literally library might be a good way to go? Or would you prefer to avoid adding the dependency? At a quick glance it looks like it would need to be done independently for scala 2/3.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, Literally is the way to go. We can save it for a followup.


def unsafe(labels: String*): LTree = LTree(labels.toList)

def fromString(s: String): Either[String, LTree] = {
Copy link
Member

Choose a reason for hiding this comment

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

It seems like we could do all of this with a single regex.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're probably right. My regex-foo is limited but I can try to tackle it when I get a little more free time.

val MaxTreeLength = 65535

private val Separator = '.'
private val ValidLabelRegex = s"""^[A-Za-z0-9_]{1,$MaxLabelLength}$$""".r
Copy link
Member

Choose a reason for hiding this comment

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

This is actually more restrictive than the implementation, which apparently depends on the character encoding, which Skunk requires to be UTF-8. So foo.βar.baz is a legal lpath. But unless we look at the source it's unlikely we'll be able to figure out exactly what it's looking for.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I adjusted the label regex such that it seems to pass your example but I'm sure that doesn't necessarily meet the spec.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah the spec is probably "whatever the implementation does", which we might want to look at. It would be nice to follow the same rules on the Skunk end.

Copy link
Contributor Author

@cranst0n cranst0n Sep 10, 2021

Choose a reason for hiding this comment

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

I think this and this are the relevant implementations used to check is the character is allowable for ltree.

This comment was marked as resolved.

@ohuu
Copy link

ohuu commented Jul 4, 2022

Is this PR ready to merge? I'm using ltree in a project

@mpilquist mpilquist merged commit 5b9e7ad into typelevel:main Jan 18, 2023
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.

5 participants