[
https://issues.apache.org/jira/browse/OPENJPA-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Heath Thomann closed OPENJPA-2627.
----------------------------------
Resolution: Fixed
Fix Version/s: 2.4.1
2.2.3
> Create an option to disable column type checking errors during schema
> validation.
> ---------------------------------------------------------------------------------
>
> Key: OPENJPA-2627
> URL: https://issues.apache.org/jira/browse/OPENJPA-2627
> Project: OpenJPA
> Issue Type: Improvement
> Components: usability
> Affects Versions: 2.2.3, 2.4.1
> Reporter: Heath Thomann
> Assignee: Heath Thomann
> Priority: Trivial
> Fix For: 2.2.3, 2.4.1
>
>
> I have a customer scenario (as I'll describe in a moment) that requires them
> to set the following property:
> <property name="openjpa.jdbc.SchemaFactory" value="native(ForeignKeys=true)"/>
> When I have the customer set this property, OpenJPA throws this exception:
> org.apache.openjpa.persistence.ArgumentException:
> "com.xxx.yyy.Parent.phone" declares a column that is not
> compatible with the expected type "varchar". Column details:
> Full Name: Parent.phone
> Type: varbinary
> In other words, the customer's column for 'phone' is defined as varbinary in
> their SQL Server database. This type seems to be specific to SQL Server.
> The JPA entity defines 'phone' as a String. Therefore, from OpenJPA's point
> of view, this is a mismatch. The customer only sees this when the above
> property is set, without this property OpenJPA doesn't do the schema
> validation as such this goes unchecked and all works fine. While OpenJPA
> views this as a mismatch and doesn't allow them to go on, the JDBC driver and
> database allows the String to be stored into an SQL Server varbinary.
> The scenario under which they are required to set the SchemaFactory is the
> typical SQL miss ordering that can occur when OpenJPA doesn't know about a FK
> constraint. That is, they have an FK constraint in the database between, as
> an example, a Child to Parent. OpenJPA doesn't know about this FK
> constraint. Given this, when the customer persists a new Parent and Child,
> sometimes OpenJPA inserts the Child first, which yield an FK Constraint
> Violation exception. This is nothing new and OpenJPA, and the SchemaFactory
> property was created to handle this scenario. It allows OpenJPA to view the
> database table schema, and in so doing OpenJPA can detect (learn about) the
> FK constraint which will allow it to properly order SQL statements.
> As you can see, we are in a bind here: the customer can not change their
> column type, and OpenJPA will not go on given this column mismatch. I have
> seen other cases where the use of SchemaFactory causes exceptions from column
> type checking that otherwise go unchecked and work fine when the property is
> not set. Given this, we need to allow a customer a way (property) to disable
> the column type checking. Note that I realize another option for this
> particular scenario is to use @ForeignKey. However, this requires a customer
> to change their code and is OpenJPA specific. Therefore the customer is not
> willing to use this.
> Thanks,
> Heath
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
