math functions in queries

[gavinking]

The following functions are, I believe, supported on all major databases, and it seems to me that there would be value in adding them to the query language: power(), floor(), ceiling(), round(), sign(), ln(), exp(), sin(), cos(), tan(), asin(), acos(), atan(), atan2().

One might object that we don't typically need to do trigonometry in a typical query, and that's true, but since the databases themselves support these, along with both JDBC and ODBC in their function escape syntax, there's almost no cost to including these functions in the list.

If nobody objects to this idea, I will write up a proposal.

[m-reza-rahman]

Honestly I don't see these as being too frequently used in Jakarta Persistence queries. It may be best to just leave these in the realm of native queries if an application really needs these? I would assign this very low priority...

[gavinking]

Honestly I don't see these as being too frequently used in Jakarta Persistence queries.

Well sign(), round(), floor(), and ceiling() are certainly useful, and used. The fact that JPA has no function for rounding a numeric value isn't good.

The others less so, that's for sure, but all programming languages have them, along with all databases AFAIK, and along with both ODBC and JDBC. That is to say: everything except JPA supports them.

I would assign this very low priority

I agree that it's a relatively low priority. However, since it involves very little work, and since I've already volunteered to do the work, I'm not sure why the low priority matters to you.

[beikov]

I agree that these functions are important and should be specified. It would be a pity if the persistence standard in Java, Jakarta Persistence, wouldn't specify these obviously very common standard functions.

[m-reza-rahman]

The only reason priority matters is to help triage things. I would hope effort would be put into other work items ahead of this one.

[gavinking]

I would hope effort would be put into other work items ahead of this one.

Then I hope you're paying me to work on things you want me to work on. Are you?

[m-reza-rahman]

I think this is getting needlessly abrasive. I am merely stating an honest opinion cordially in response to your question with regards to prioritization. I am not suggesting anything of what you should or should not be choosing to work on personally as part of your employment expectations. That is up to you and your employer.

[gavinking]

Good, much better. So, as I said above, I'm happy to do the work of writing up the spec/API changes and submitting a PR. (This would also impact the criteria API of course.)

So what I would really like to hear is:

• if anyone has any technical objection to this proposal, or think it's something we simply shouldn't do, for whatever reason, or if
• any people who actually work on JPA implementations object for some reason, and wouldn't want to implement this?

Obviously we shouldn't add things to the spec that other implementors of JPA don't want to implement in their products.

[gavinking]

Related: #171

I didn't notice that there was a pre-existing issue requesting the round() function.

[beikov]

I guess https://github.com/eclipse-ee4j/jpa-api/pull/351 covered most functions. So the only ones left now are the trigonometric functions

• sin()
• cos()
• tan()
• asin()
• acos()
• atan()
• atan2()

[andyjefferson]

radians() and degrees() are also in that trig category, for people doing geospatial.

[gavinking]

It's probably more useful to have pi than radians() and degrees(), since it's not that hard to write *180/pi.

[gavinking]

I'm going to close this one, since the most important math functions are now available. Trigonometric functions, if we want them, would be a separate issue.