Rochelle Raccah wrote:
> Marina Vatkina wrote:
>
>> Rochelle Raccah wrote:
>>
>>> Marina Vatkina wrote:
>>>
>>>> Rochelle Raccah wrote:
>>>>
>>>>> Mitesh Meswani wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Rochelle Raccah wrote:
>>>>>>
>>>>>>> Okay, the verifier bug goes away if a stateless session bean is
>>>>>>> added to the project, so:
>>>>>>>
>>>>>>> 1) For cmp this is still an issue - is there a better thing to
>>>>>>> generate than Object for this case? Can we handle char with the
>>>>>>> formOfUse change?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The current cmp runtime is not aware of NCHAR data type and does
>>>>>> not call formOfUse(). It should not be a big effort putting the
>>>>>> support if we are able to distinguish at run time that a given
>>>>>> column is of this type. Then the issue is, since this is not
>>>>>> standard jdbc type, our dbmodel mignt not be able to carry this
>>>>>> information. How did you solve this issue for generation?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Right. We didn't solve it for generation - that's what the nb bug
>>>>> is about =). Any advice would be appreciated.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> It should be treated as a String. N means (extra?) unicode support
>>>> for the type
>>>> after it.
>>>
>>>
>>>
>>>
>>> So, if the sqltype is set to CHAR as the original proposal, it would
>>> be generated as a String for both CMP and JPA. We'd have no further
>>> support (formOfUse) in either case, so I think it would verify and
>>> deploy without errors. I'm not sure if it would run without errors.
>>> If we generate this way and *don't* report that the type is
>>> unsupported, isn't that almost as bad?
>>
>>
>>
>> Yes. Unless the user relies on another provider that does the right thing
>> (until we can support it ourselves :().
>
>
> Yes what? We should generate String/CHAR or we should not because it's
> unsupported?
Yes - it's almost as bad, but that will restrict NB users that can otherwise
utilize other providers (or won't need an NB update if we add support for
formOfUse().
thanks,
-marina
>
> Rochelle
>
>>
>> -marina
>>
>>>
>>> Thanks,
>>> Rochelle
>>>
>>>>
>>>> -marina
>>>>
>>>>>
>>>>> Thanks,
>>>>> Rochelle
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Mitesh
>>>>>>
>>>>>>> 2) For JPA, we generate
>>>>>>> @Id
>>>>>>> @Lob
>>>>>>> @Column(name = "GENRE", nullable = false)
>>>>>>> private Object genre;
>>>>>>> It verifies correctly, but is it okay?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rochelle
>>>>>>>
>>>>>>> Rochelle Raccah wrote:
>>>>>>>
>>>>>>>> Both, I think. Right now, the generated JPA has fields of type
>>>>>>>> Object as well, but the verifier is not working for it:
>>>>>>>> <https://glassfish.dev.java.net/issues/show_bug.cgi?id=1049>
>>>>>>>>
>>>>>>>> Rochelle
>>>>>>>>
>>>>>>>> Marina Vatkina wrote:
>>>>>>>>
>>>>>>>>> Rochelle,
>>>>>>>>>
>>>>>>>>> The NB bug talks about cmp - is it cmp or JPA (or both) related
>>>>>>>>> question?
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> -marina
>>>>>>>>>
>>>>>>>>> Peter Krogh wrote:
>>>>>>>>>
>>>>>>>>>> Supporting 'N' Types requires Oracle Specific JDBC calls, that
>>>>>>>>>> are not currently supported by TopLink Essentials. Support
>>>>>>>>>> for N types sounds like a good feature request to be added to
>>>>>>>>>> the issue tracker.
>>>>>>>>>>
>>>>>>>>>> Note: Adding this support may require changes to the build
>>>>>>>>>> system to compile classes with references to Oracle JDBC
>>>>>>>>>> specific classes.
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Rochelle.Raccah_at_Sun.COM
>>>>>>>>>> [mailto:Rochelle.Raccah_at_Sun.COM]On Behalf
>>>>>>>>>> Of Rochelle Raccah
>>>>>>>>>> Sent: Tuesday, August 29, 2006 8:29 PM
>>>>>>>>>> To: persistence_at_glassfish.dev.java.net
>>>>>>>>>> Subject: how to map NVARCHAR2 columns
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> For background, please see
>>>>>>>>>> <http://www.netbeans.org/issues/show_bug.cgi?id=68997>.
>>>>>>>>>>
>>>>>>>>>> The question is, are NVARCHAR2 columns allowed in a schema?
>>>>>>>>>> If so, how
>>>>>>>>>> can they be mapped? And, do we have a way to generate the
>>>>>>>>>> formOfUse
>>>>>>>>>> calls if necessary?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Rochelle
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>