AutoQuery hiding all records with status = inactive

1

On some of my entities I have an enum:

public enum CompanyStatus
{
    Active,
    Inactive
}

When it is set to Inactive it seems AutoQuery automatically filters it out from the response.

Inside the /locode dashboard if I try to set the filter to show inactive it generates this query and will have 0 results:

image
?include=total&take=25&StatusIn=Inactive

I am not sure why this is returning 0 results.

If I manually go to:

?include=total&take=25&Status=Inactive

Then I get the list of inactive records but I cant see them in locode grid as it uses StatusIn and returns 0 results (just for inactive, it will work fine when set to active)…

Any ideas?

2

I’m assuming it’s because it ignores querying default values since passing in the first value of an non nullable Enum is the same as default(CompanyStatus) which is the same as not passing anything at all.

You should have a different default value for enums, either by making the property nullable:

public class Company
{
    public CompanyStatus? Status { get; set; }
}

Or including a different value for unset enums, e.g:

public enum CompanyStatus
{
    Unknown, //= 0 or default(CompanyStatus)
    Active,
    Inactive
}

Or if the enum only has 2 states it can be done with a single bool property:

public class Company
{
    public bool? Active { get; set; }
}
3

ah. I planned on adding more in.

I tried adding a different default state and a few more into enum but I am getting same behaviour, no change. It won’t show inactive with StatusIn= but will with Status=

4

What’s the SQL that’s being generated?

The Logging and Introspection docs shows different ways of logging the SQL that’s executed.

1 Like
5

Wow, I never knew about that logging and profiling feature, very cool.

I had made a mistake on the query model, sorry to bother you. You have the patience of a saint!

Thanks Mythz, I’ll try not to bother you for at least another hour :wink:

6

Ok great that it’s resolved, but can you please spend more time researching issues before reporting them as issues since we don’t have all the information needed to be able to repro and identify them which makes it even more time consuming trying to chase ghosts when it’s not an issue we’d ever be able to identify from the info provided.

It’s better to create small stand-alone repro’s on GitHub that we can download and run locally, so it contains all the context needed to verify, repro and identify actual issues.

7

Yes point taken. In my defence I did check all documentation for any mention of the behaviour to automatically hide records with status and couldn’t find any mention or any mention on stack overflow. I wrongly assumed the issue was with the magic behaviour but I should have made a stand alone repo to be sure.