Hi Markus,
This is a very good question, and at this point somewhat philosophical
as well ;).
TopLink code assumes that any particular database provides only one type
of native sequence support, so it's for the user's benefit to get whatever
is there even if they specified the other type. This is true for all but one
tested database - PostgreSQL supports both types: identity and sequence, and
its users can so far use the only the one that TopLink supports.
Which means that unless you are willing to spend time and change the whole
native sequence story, your "fake" solution is the one expected.
thanks,
-marina
Markus KARG wrote:
> Lance,
>
>> While, i am still not an expert on Toplink Essentials codeline yet, my
>> take is that you are reading too much into the method names.
>> Looking at this and the other platforms, this to me is just the way to
>> access identity/sequences... etc.
>> So I do not see you are faking a sequence, just providing the correct
>> plumbing in order to provide the support required for the given
>> platform, in this case, SQL Anywhere, to return the auto-generated
>> values, which in this case is done via an identity column.
>
> Just for my own curiosity:
>
> A programmer can write @GeneratedValue(strategy = SEQUENCE) or
> @GeneratedValue(strategy = IDENTITY), and he expects SQLAnywherePlatform
> to do different things. Is SQLAynwherePlatform behaving correctly in the
> case that SEQUENCE is used but not IDENTITY?
>
> Also, entity-persistent-tests is running tests using SEQUENCE. In fact
> that tests failed. Then I added support for IDENTITY. Now the tests
> pass. So it seems, the SEQUENCE tests think SQL Anywhere supports
> sequences. But actually, it does not.
>
> Since I do not want to provide a lie, is it correct what I programmed,
> or do I have to remove parts of it?
>
> Thanks
> Markus