Jiwa

Hi Mike,

Using the c# types generated by 7.182 is producing a list of compiler errors for any property listed as Nullable, and reports as

Severity Code Description Project File Line Suppression State
Error CS0722 'Nullable': static types cannot be used as return types WebApplication1.ServiceModel 6110 Active
Severity Code Description Project File Line Suppression State
Error CS0721 'Nullable': static types cannot be used as parameters WebApplication1.ServiceModel 6110 Active

It starts at AR_HistoryQuery property StatusBetween, then StatusIn etc.

Replacing Nullable with string[] makes everything compile but obviously is not the best course of action but worked since I wasn't looking at those objects with original errors.

Hi Stuart,

Yes - I noticed this also shortly after we released 7.00.182.00 and logged a bug with ServiceStack.

It's since been fixed, but we need to release a new build with the latest ServiceStack (4.5.13).

The problem only occurred because we added Query classes for each table in JiwaServiceModel.dll - and a few versions ago ServiceStack changed a lot of their types to be Nullable - and they didn't quite get it all right.

Mike

Hi Mike,

Thanks for the update any idea when the release will be?

As I am not sure if my work around works as when I try something as simple as

Code: Select all

                        DB_MainQuery qry = new DB_MainQuery();
                        qry.AccountNameContains = "and";
                        //qry.Skip = 2;
                        //qry.Take = 20;
                        QueryResponse<DB_Main> qresp = client.Get<QueryResponse<DB_Main>>(qry);

I get a bad argument exception

Code: Select all

{400 ArgumentException
Code: ArgumentException, Message:  requires 2 values
Server StackTrace:
 [DB_MainQuery: 7/1/2017 12:17:33 AM]:
[REQUEST: {DebtorIDBetween:[],DebtorIDIn:[],AccountNoBetween:[],AccountNoIn:[],NameBetween:[],NameIn:[],Address1Between:[],Address1In:[],Address2Between:[],Address2In:[],Address3Between:[],Address3In:[],Address4Between:[],Address4In:[],PostCodeBetween:[],PostCodeIn:[],PhoneBetween:[],PhoneIn:[],FaxBetween:[],FaxIn:[],BankNameBetween:[],BankNameIn:[],BankAccBetween:[],BankAccIn:[],BSBNBetween:[],BSBNIn:[],AccountNameContains:and,AccountNameBetween:[],AccountNameIn:[],TaxExemptNoBetween:[],TaxExemptNoIn:[],ClassificationIDBetween:[],ClassificationIDIn:[],EmailAddressBetween:[],EmailAddressIn:[],AltAccountNoBetween:[],AltAccountNoIn:[],NotifyAddressBetween:[],NotifyAddressIn:[],ParentDebtorIDBetween:[],ParentDebtorIDIn:[],PriceSchemeIDBetween:[],PriceSchemeIDIn:[],AustPostDPIDBetween:[],AustPostDPIDIn:[],AustPostBCSPBetween:[],AustPostBCSPIn:[],TradingNameBetween:[],TradingNameIn:[],CompanyNameBetween:[],CompanyNameIn:[],ACNBetween:[],ACNIn:[],ProprietorsNameBetween:[],ProprietorsNameIn:[],FaxHeaderBetween:[],FaxHeaderIn:[],LedgerIDDebtorControlBetween:[],LedgerIDDebtorControlIn:[],LedgerIDDebtorSalesBetween:[],LedgerIDDebtorSalesIn:[],LedgerIDDebtorDiscountsBetween:[],LedgerIDDebtorDiscountsIn:[],LedgerIDDebtorSourcedInvoicesBetween:[],LedgerIDDebtorSourcedInvoicesIn:[],LedgerIDDebtorDebitAdjustmentBetween:[],LedgerIDDebtorDebitAdjustmentIn:[],LedgerIDDebtorSourcedReceiptsBetween:[],LedgerIDDebtorSourcedReceiptsIn:[],LedgerIDDebtorCreditAdjustmentBetween:[],LedgerIDDebtorCreditAdjustmentIn:[],LedgerIDDebtorFreightBetween:[],LedgerIDDebtorFreightIn:[],LedgerIDDebtorInsuranceBetween:[],LedgerIDDebtorInsuranceIn:[],LedgerIDDebtorRealisedGainLossBetween:[],LedgerIDDebtorRealisedGainLossIn:[],LedgerIDDebtorUnRealisedGainLossBetween:[],LedgerIDDebtorUnRealisedGainLossIn:[],ABNBetween:[],ABNIn:[],BPayReferenceBetween:[],BPayReferenceIn:[],FXCurrencyIDBetween:[],FXCurrencyIDIn:[],Category1IDBetween:[],Category1IDIn:[],Category2IDBetween:[],Category2IDIn:[],Category3IDBetween:[],Category3IDIn:[],Category4IDBetween:[],Category4IDIn:[],Category5IDBetween:[],Category5IDIn:[],BO_Priorities_RecIDBetween:[],BO_Priorities_RecIDIn:[],PricingGroupIDBetween:[],PricingGroupIDIn:[],CountryBetween:[],CountryIn:[],FR_Carriers_RecIDBetween:[],FR_Carriers_RecIDIn:[],FR_CarrierServices_RecIDBetween:[],FR_CarrierServices_RecIDIn:[],CarrierAccountNoBetween:[],CarrierAccountNoIn:[],Skip:2,Take:20}]
System.ArgumentException:  requires 2 values
   at ServiceStack.TypedQuery`2.AddCondition(SqlExpression`1 q, String defaultTerm, String quotedColumn, Object value, QueryDbFieldAttribute implicitQuery)
   at ServiceStack.TypedQuery`2.AppendUntypedQueries(SqlExpression`1 q, Dictionary`2 dynamicParams, String defaultTerm, IAutoQueryOptions options, Dictionary`2 aliases)
   at ServiceStack.TypedQuery`2.CreateQuery(IDbConnection db, IQueryDb dto, Dictionary`2 dynamicParams, IAutoQueryOptions options)
   at ServiceStack.AutoQuery.CreateQuery[From](IQueryDb`1 dto, Dictionary`2 dynamicParams, IRequest req)
   at ServiceStack.AutoQueryServiceBase.Exec[From](IQueryDb`1 dto)
   at __AutoQueryServices.Any(DB_MainQuery )
   at lambda_method(Closure , Object , Object )
   at ServiceStack.Host.ServiceRunner`1.Execute(IRequest request, Object instance, TRequest requestDto)
}

It could be from when you renamed all the Nullable occurrences to string[] in the service reference created by ServiceStack.

I'd try string?[] instead.

I've tried testing this myself, but my dev environment is giving me a hard time - I'm in Nuget package hell atm!

EDIT: If it's any help, this is what our unit test for the DB_MainQuery looked like last time I had it working:

Code: Select all

[Test]
public void DB_MainQuery()
{
   // Try before logging on to make sure we get a 401
   // GET: /Debtors/
   var DB_MainQueryRequest = new DB_MainQuery() { AccountNoIn = null, NameIn = null, AltAccountNoIn = null, LastSavedDateTimeIn = null };
   ServiceStack.QueryResponse<DB_Main> DB_MainQueryResponse;
   var ex = Assert.Throws<ServiceStack.WebServiceException>(() => DB_MainQueryResponse = client.Get(DB_MainQueryRequest));
   Assert.AreEqual(401, ex.StatusCode);

   Logon();

   DB_MainQueryRequest = new DB_MainQuery() { AccountNoIn = null, NameIn = null, AltAccountNoIn = null, LastSavedDateTimeIn = null };
   DB_MainQueryResponse = client.Get(DB_MainQueryRequest);
   Assert.AreEqual(LastHttpStatusCode, System.Net.HttpStatusCode.OK);

   // Let's assume we expect to get at least one debtor back - demo data has many debtors.
   Assert.Greater(DB_MainQueryResponse.Results.Count, 0);
}

Ok, so I'm now able to test this and get the same result as you :

Code: Select all

Test Name:   DB_MainQuery
Test FullName:   JiwaAPITests.APITests.DB_MainQuery
Test Source:   C:\VSTS\Jiwa 7\Jiwa\JiwaAPITests\JiwaAPITests\APITests.cs : line 5934
Test Outcome:   Failed
Test Duration:   0:00:04.32

Result StackTrace:   
at ServiceStack.ServiceClientBase.ThrowWebServiceException[TResponse](Exception ex, String requestUri)
   at ServiceStack.ServiceClientBase.ThrowResponseTypeException[TResponse](Object request, Exception ex, String requestUri)
   at ServiceStack.ServiceClientBase.HandleResponseException[TResponse](Exception ex, Object request, String requestUri, Func`1 createWebRequest, Func`2 getResponse, TResponse& response)
   at ServiceStack.ServiceClientBase.Send[TResponse](String httpMethod, String relativeOrAbsoluteUrl, Object request)
   at ServiceStack.ServiceClientBase.Get[TResponse](IReturn`1 requestDto)
   at JiwaAPITests.APITests.DB_MainQuery() in C:\VSTS\Jiwa 7\Jiwa\JiwaAPITests\JiwaAPITests\APITests.cs:line 5946
Result Message:   ServiceStack.WebServiceException :  requires 2 values



I changed the types to string?[] and soon discovered you can't do that, so as a hack I tried List<Nullable<byte>> which compiles, but I get the above error still.

I shall continue looking, but I think the easiest solution is for us to build with the latest ServiceStack which will hopefully resolve the issue. When that will be is an unknown - I've been diverted to another project and Scott's away all next week. I might be able to get one done sometime mid next week - depending on how productive I am with my current task.

Hi Mike,

Thanks for the update I have to see a new client this week(Wednesday) and explain the advantages of the web api, so it would be nice to know that by roughly the same time that I do that, I know if they download it this should be hopefully resolved.

Cheers

SBarnes wrote:Hi Mike,

Thanks for the update I have to see a new client this week(Wednesday) and explain the advantages of the web api, so it would be nice to know that by roughly the same time that I do that, I know if they download it this should be hopefully resolved.

Cheers

Wednesday might be a bit iffy at this point.

I've tried the latest 4.5.13 ServiceStack libraries from their MyGet (which is their pre-release packages) which are purportedly the version which fixes the Nullable array problem - but it's introduced a new problem - "Could not load type 'ServiceStack.StrictModeException' from assembly 'ServiceStack.Interfaces, Version=4.0.0.0, Culture=neutral, PublicKeyToken=e06fbc6124f57c43'."ServiceStack.StrictModeException"

It looks like this StrictModeException was added 4 days ago to SS, so I'm trying to work out if their prerelease is the problem or something else.

It may very well be that we need to wait for SS to get a stable version out with the changes we required for the QueryTypes which doesn't introduce new issues.

EDIT: I've been able to reproduce the issue in a clean, isolated project and have reported it to the Service Stack team. Until that is addressed I won't be able to progress on this.

Hi Mike,

if I am reading this correctly looks like SS solved your problem?

SBarnes wrote:Hi Mike,

if I am reading this correctly looks like SS solved your problem?

Yes, but now I have a new one. The client code generated has invalid attributes around the Request classes - figuring that one out now.

Hi Mike,

Thanks for the update, by the way thanks again for having a look at this on the weekend and in your own time, when I made the original post I hadn't actually expected any response until during next week.

Your efforts as is your patience are always appreciated.