Hi, Just catching up. I agree with Renato about all the filter issues as you probably have guessed. Regarding sorting now. In pywrapper I have left the "how" it gets sorted to the underlying database type. And that might be very different to the conceptual or model one. But I wonder if it is really important to be specific about the sorting order? At least it is sorted in some stable way.
I agree it makes sense to announce that datatype in the capabilities, so you understand the sorting. That can easily be done using xml schema datatypes (should cover nearly all db types). The underlying datatype also affects what COPs you can use with it. You will get an error with PyWrapper for example if you do a LIKE on a date or integer type.
If we will force people to adapt their datatypes in the underlying database this is quite a burden. This way every data provider will need a copy of their database and they will never be able to use the original dataset. That might not be a problem and in fact this allows you to do quite some data transformation in between, but for many providers I know this will be too much - or they will close to never update their data clone.
So for now I would suggest to indicate the underlying db type in the concept capabilities and just use whatever there is for ordering. We should probably come up with a standard error for the CopNotSupportedByLocalDatatype. How do you deal with this in TapirLink Renato?
Markus
"Renato De Giovanni" wrote on 26.11.2007 2:18 Uhr:
Hi Roger,
Yes, I fully agree that the spec should be revised to be clearer about data types. I also like the idea of using "string" as a default data type. Let's just wait a bit more to see if there are other suggestions and opinions.
Best Regards,
Renato
On 23 Nov 2007 at 21:22, Roger Hyam wrote:
Hi Renato,
I think I follow you - but I'll probably believe it when I see it spelled out in the spec.
I think some of the sorting stuff should be in the specification. There are some things there that are implied but not expressed.
- schema concepts should/must only be mapped to columns of the same
data type in the host database or at least wrappers should act as if they are.
- Values in queries (and parameters) should use the xsd serialization
of date (and other things?). It is the wrappers responsibility to present the correctly to the underlying database.
- If the concept does not have a data type the behaviour of orderby,
greaterthan and lessthan are undefined? If we stick to XML Schema concept schemas then they default to string so maybe the default should be to act as string.
What do you think?
Roger
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir