In the object below we can not set the connection to use. In the past, everything worked simply by using the NamedConnectionAttribute attribute. Since we upgraded to version 5.12.0 we can no longer have populated the UseNamedConnection property of the AutoQuery object.
/// <summary>
/// Class for query Log data transfer object.
/// </summary>
/// <seealso cref="ServiceStack.QueryDb{Log, LogDto}" />
[ConnectionInfo(NamedConnection ="CoreConnection")]
[Route("/query/Logs")]
public class QueryLogsRequest: QueryDb<Log, LogDto>
{
}
The [NamedConnection] attribute is preferred on DTOs since it’s in ServiceStack.Interfaces (i.e. only dep your ServiceModel DTOs should depend on). Can you explain why you can no longer use it?
Until yesterday we used it as recommended in 2016 when that code was written. Only we realized that in an environment with several db no longer worked (what in the past went without problems). Now look for the db indicated in the named Connection but then go to look for the table in the default connection database. The UseNamedConnection property of the AutoQuery instance continues to be null.
UseNamedConnection is a property of the AutoQuery singleton that’s populated from the AutoQueryFeature.UseNamedConnection plugin configuration which sets the default Named Connection to use, it’s never been populated from Request DTO or Service attributes.
You can check which connection gets used by creating a custom implementation that resolves the DB and calls AutoQuery manually, e.g:
// Sync
public object Any(QueryLogsRequest query)
{
using var db = AutoQuery.GetDb(query, base.Request);
// check db used
var q = AutoQuery.CreateQuery(query, base.Request, db);
return AutoQuery.Execute(query, q, base.Request, db);
}
Thank you Demis for your suggestions. In our solution we have tons of services, requests and DTOs so we look for a solution that we can inherit from a base class in a generic way for all or almost everyone. So we will probably opt to move the NamedConnectionAttribute to DomainEntities by removing it from Requests where it seems not to work.
I’m still not clear on why & what doesn’t work (if you send a link to a standalone repro on GitHub I can tell you why), but you can also overrideGetDbConnection() in your AppHost to be able to customize which named connection is used for each request, e.g. the default implementation will use any DbInfo populated in a Request Filter as well as [NamedConnection] annotated on the Request DTO:
If you need a custom generic solution, you’d either want to populate DbInfo in a Request Filter or override and customize this method which is used when using Db in the base Service class or AutoQuery Services.
Demis thanks for your suggestions. I’m trying to explain how we use your framework.
we have created a service framework, based on your ServiceStack, for the management of business engines on heterogeneous domains. To reduce the time it takes to create, customize, and manage, we’ve built some base classes for services, business logic, and repositories. In some of these classes we have our own implementation that exploits the potential of AutoQuery to allow searches with dynamic filters (we love AutoQuery and its potential - it only lacks the AndOr search mix that is required in some scenarios). Up to ServiceStack version 5.8.0, our Request objects like this
using Msa.Core.Models.Entities;
using ServiceStack;
namespace Msa.Core.Models.Dto.Logs
{
[NamedConnection("AppConnection")]
[Route("/query/Logs")]
public class QueryLogsRequest : QueryDb<Log, LogDto>
{
}
}
they used namedConnectionAttribute to query the data on the database table corresponding to the NamedConnection. These days we are updating old apps that used version 5.8.0 with version 5.12.0. This is how we discovered that the behavior is no longer like that of version 5.8.0. Given the tight deadlines we solved by marking the domain entities (classes that map the database through OrmLite) with that attribute by removing it from the Request DTOs.
[NamedConnection("AppConnection")]
[Schema("Core")]
[Alias("Logs")]
public class Log: DomainEntityWithDescription
{
...
}
So it works but limits us some highly dynamic scenarios that we have rewritten using a custom attribute that reads a header in the Request in which we find the name of the NamedConnection.
I hope you’ll get the big picture clearer. Preparing a repo in GitHub, these days it is not really possible (too busy with updates and little time to do it). Maybe later we could think about it.
The issue is that I can’t repro the issue from what’s provided. Your example is just showcasing that you’re using [NamedConnection] attribute on the AutoQuery Request DTO and data model which we also do in our AutoQueryTests:
Both of which works as expected. In order to be able to investigate any further I would need a minimal verifiable repro I can run locally to repro the issue. It doesn’t have to include any of your App, just a stand-alone example that shows what’s not working.
