Issue Details (XML | Word | Printable)

Key: NUCJPA-66
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Testcase Required Testcase Required
Assignee: Unassigned
Reporter: Todd Vierling
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
DataNucleus API JPA

@Column(columnDefinition) implementation is wrong

Created: 12/Feb/10 01:01 AM   Updated: 26/Apr/10 03:40 PM   Resolved: 14/Apr/10 01:47 PM
Component/s: API
Affects Version/s: 2.0.1
Fix Version/s: 2.1.0.m2

Environment: Should affect all RDBMS's; tested on PostgreSQL.

Datastore: PostgreSQL
Severity: Development


 Description  « Hide
According to NUCJPA-28, @Column(columnDefinition) is now implemented as a string appended to the inferred type when generating schema. This is wrong. The whole point is to allow the programmer to specify the column type exactly, e.g.:

  @Basic
  @Column(columnDefinition = "numeric(5,2) default 1.01")
  float variance;

Here, rather than using the driver-specific mapping for 'float', the programmer is telling you to use exactly the SQL standard 'numeric' type with explicit precision and scale, DDL default value, and no 'not null' constraint.

If columnDefinition is set, it should override all the related attributes (e.g., nullable, length, precision, scale), as the columnDefinition contains the EXACT backend-specific DDL definition for that column's type including all of these four attributes. The Javadoc for @Column is sparse, but it specifically notes:


public abstract String columnDefinition
    (Optional) The SQL fragment that is used when generating the DDL for the column.
    Defaults to the generated SQL to create a column of the inferred type.


Taking the contrapositive of this, if columnDefinition is *not* the default (empty) value, then the inferred type is not used at all. Yes, this means that a programmer can make a type that conflicts with the Java type. However, that flexibility is the whole point: how else can you make the schema generator spit out the type "vendorspecific_floatingpoint2" (which otherwise behaves like a float or double in JDBC)?


Sort Order: Ascending order - Click to sort in descending order
Todd Vierling added a comment - 12/Feb/10 01:06 AM
Oh, and related, if I try to create a type thus:

  @Basic
  @Column(precision = 5, scale = 2)
  float variance;

I don't get a numeric(5,2) column - I still get the driver's equivalent datatype for 'float' (which, amusingly, is 'double precision' on PostgreSQL, even though 'real' is the direct counterpart). This is not technically a bug as it is not JPA-specified to work (AFAICT), but it should illustrate the problem with the improper columnDefinition logic.

A numeric(5,2) column doesn't need a BigDecimal to do its job; a float can handle those values fine, and JDBC is happy to handle the value that way too. As of this writing, there's no way to map a non-BigDecimal type to a numeric(p,s) DDL in the schema generator.

Andy Jefferson added a comment - 20/Feb/10 07:42 AM - edited
4 comments deleted since not adding anything constructive to any situation.

The front page of JIRA (Dashboard) mentions the need for a testcase to demonstrate issues (to avoid any possible confusion in expected and actual behaviour). The datanucleus.org docs also mention this. The DataNucleus forum also mentions this.
 
You can choose to not provide a testcase if you so wish (due to time reasons, or whatever), but at the end of the day when someone comes along here in *their spare time* and decides which issue to focus on, one that has a testcase meeting the projects own defined guidelines (and every project has a perfect right to define their own guidelines for what is a testcase) will clearly be chosen first; so its an opportunity for the reporter to help out, and to get the issue that they have met have a higher priority. No problem if you don't provide a testcase matching this, and no issue with necessary basic info provided in the report is rejected for absence of testcase, just that it gets looked at later.

Thanks for the report.

Andy Jefferson added a comment - 14/Apr/10 01:47 PM
SVN trunk aligns the use of columnDefinition with the alternative interpretation of the JPA spec