FilterString confusing behavior on TableQuery depending on creation path about azure-storage-net HOT 4 CLOSED

Thanks for reporting this. This is the expected behavior since LINQ provides methods like where,select etc in order to specify your filters. The LINQ expression is parsed and the appropriate FilterString is set thereby overwriting the FilterString you set on the query itself. However, checking if it’s a LINQ query and throwing an error if the FilterString is also set(instead of silently ignoring it) sounds better and we will track this so we can fix it in an upcoming release.  Thanks!

from azure-storage-net.

Just came across this issue ourselves. We started off using the factory methods to generate a query which was then filtered via LINQ but moved to use FilterString when we needed to apply more complex filtering than was supported via LINQ. I second the notion that the API should be more predictable here. If the FilterString itself doesn't apply in this scenario then ideally it would be hidden completely, however raising an error would certainly be better than silent failure.

from azure-storage-net.

Hi,

Since the release of CosmosDB Table sdk package, support for Table service has transitioned to CosmosDB team.

Please email the team at : [email protected] for more information.

Thanks!

from azure-storage-net.

This FilterString behaviour is absolutely bizarre.

@erezvani1529 isn't the code still developed on this repo?

from azure-storage-net.