Patrick,
Not getting a lot of activity on this thread yet... I'll kick in my two
cents worth...
I agree with your overall direction -- attempting to keep the annotation
support in synch with the xml support as outlined in the JPA spec. All
annotations defined by the JPA spec seem to have a corr
> As you have pointed out, this gets a bit trickier due to the
> xml schema
> definitions for the orm.xml file. We can't just define new
> stanzas and
> expect the orm.xml files to be portable across persistence providers.
But do we care? That is, how do we want to balance portability vs. ease
I'm interested in using OpenJPA for a project which would use Postgres. I
noticed that it says "Empty string/char values are stored as NULL." in the
known issues
(http://incubator.apache.org/openjpa/docs/latest/manual/manual.html#dbsupport_postgresql_issues).
Can anyone back that up with documen
Jim Cullison wrote:
>
> I'm interested in using OpenJPA for a project which would use Postgres. I
> noticed that it says "Empty string/char values are stored as NULL." in the
> known issues
> (http://incubator.apache.org/openjpa/docs/latest/manual/manual.html#dbsupport_postgresql_issues).
> Can
Kevin Sutter wrote:
>
> As you have pointed out, this gets a bit trickier due to the xml schema
> definitions for the orm.xml file. We can't just define new stanzas and
> expect the orm.xml files to be portable across persistence providers.
>
But using an openjpa namespace still makes it vali
Thanks for confirming that the behavior is the same as what I am seeing.
Maybe the documentation needs that line removed?
Jim
On 12/5/06, roger.keays <[EMAIL PROTECTED]> wrote:
Empty strings store as empty strings for me on 7.4 and 8.1
