Just wondering -- does support for the Xml db type said to be coming up in v2 include changes to the query engines? Will it be possible to sort/filter using those fields (using xpath and FLOWR or whatever in the background)?

The Xml support as it is now in 1.0.2005.1 is the same as with v2. We thought about adding XQuery support, but these queries can't use parameters. This means that we had to concat the provided string into the query which can lead to sql injection attacks if you're not careful and we want to avoid that at all costs.

It's still possible though, through a custom IPredicate implementation ala FieldCompareValuePredicate, however we won't support it.

This also means that Xml field data is usable in v2 as it is now.

Otis wrote:

... We thought about adding XQuery support, but these queries can't use parameters ...

This is a valid XQuery:

SELECT [Name].query('data(/Cultures/Culture[@id=sql:variable("@CultureID")]/Name)') FROM Category

yk wrote:

Otis wrote:

... We thought about adding XQuery support, but these queries can't use parameters ...

This is a valid XQuery:

SELECT [Name].query('data(/Cultures/Culture[@id=sql:variable("@CultureID")]/Name)') FROM Category

Yes, but you forget that the xquery string itself is also passed to the query, how else would you specify data(/Cultures/Culture etc. ?

Otis wrote:

Yes, but you forget that the xquery string itself is also passed to the query, how else would you specify data(/Cultures/Culture etc. ?

You are right, I was under the impression that the xquery expression could be a variable. It can't -- It has to be a literal.

yk wrote:

Otis wrote:

Yes, but you forget that the xquery string itself is also passed to the query, how else would you specify data(/Cultures/Culture etc. ?

You are right, I was under the impression that the xquery expression could be a variable. It can't -- It has to be a literal.

Silly isn't it? I also was under teh same impression as you when I started developing it. Though I didn't proceed because it can lead to sql injection (not likely, but people are very anal about sql injection so I avoid that). If people want it, it's still possible though to add XQuery support through their own IPredicate implementation. (which you can add today if you need to, just base your FieldCompareXQueryPredicate class on the code of FieldCompareValue )

Otis wrote:

Silly isn't it? I also was under teh same impression as you when I started developing it. Though I didn't proceed because it can lead to sql injection (not likely, but people are very anal about sql injection so I avoid that).

Well, string concatenation can only really lead to injection attacks when you concatenate user inputs. In this case you will only be concatenating strings created by your own code, the user input is still parametrized.

Though it's hard to specify the query with the values as a developer who wants to filter, which was the reason why I dropped it for now. It can be later on added easily though if people really need it: an IPredicate implementation isn't that hard.

Otis wrote:

Silly isn't it? I also was under teh same impression as you when I started developing it.

Not really.

That is saying that in a statement like"

SELECT * FROM MyTable WHERE MyField = @MyValue

That is it silly that MyField has to be an object name.

BOb