I've been developing an AppEngine site which uses the Expando class to store info. I can successfully store a property in the development server. I verify the info is there with the developer (web) console, but when I run code I have the following problems:
- the hasattr(myobj, attr_name) function returns false
- the getattr(myobj, attr_name) function throws an exception
- myobj.attr_name throws an exception
- myobj.dynamic_properties() returns an empty list
All of these happen while the development (web) console reports the property is still there.
Also, if I set a new property (and commit it to the datastore) the old property disappears. This class was recently changed from a db.Model subclass to an Expando subclass. More strangely, another Expando subclass properly reports its dynamic properties.
I've re-installed the dev server (GoogleAppEngineLauncher 1.1.9 on Mac OS X 10.5.6) and cleared the datastore with no luck. I'm kind of stuck.
I figured this out. Apparently I was using the superclass'
Model.get('key')
method, instead of
db.get('key')
Duh.
Related
I am having some issues with context lifetime on my .NetCore 6 win forms application. In summary, I have a button that when clicked calls a repository which then retrieves a record from my DB and displays one value from that record in a text field. This works ok until that value changes in the database. Further clicks of the button continue to display the old value.
This is how I register my context in the winforms app
services.AddDbContext<MyContext>(b => b.UseSqlServer(connectionString));
I then register my services like this:
services.AddScoped<IMyRepo, MyRepo>();
I guess this is an issue where the form is long running and never disposes the context, hence why the result is always the same until the form is closed and reopened with a fresh context.
I am using this in my repo to force a new result each time, however is seems like a bit of a mission to do this for every request to the DB I make...
_entities.Entry(log).Reload();
Is there a cleaner way I can do this without having to do the reload?
Honestly, I wouldn't use the MS IoC AddDbContext for WinForms/WPF. There probably is a way to have it play nice with some form of lifetime scope, but I'm honestly not aware of one. I don't use it for web projects either, simply because it scopes the DbContext to the request and I like to have a bit more control over the lifetime of the DbContext in some situations. (Dealing with poisoned contexts for instance)
For web and WPF I've used a Unit of Work pattern called the DbContextScope to manage the DbContext and relationship with the Repositories. The idea being that the consumers use an injected DBContextScopeFactory to create a DbContextScope (wrapping one or more DbContext instances) and the Repositories accept an injected DbContexScopeLocator to gain access to a requested DbContextScope.
The original EF6 implementation was by Medhi El Gueddari (https://github.com/mehdime/DbContextScope || https://www.nuget.org/packages/Mehdime.Entity)
For EF Core 6: (https://www.nuget.org/packages/Zejji.DbContextScope.EFCore6)
Alternatively if the scope of a DbContext can be contained within the repository calls themselves (tracked entities don't need to be passed outside of the repository) then you could also just use an injected DbContextFactory class to provide DbContext instances on demand. The advantage of a UoW pattern like above is that you have control over the scope the DbContext instance(s) live so multiple operations can be committed together or rolled back. The DbContext instance is available between multiple repositories if needed.
I am migrating an existing ASP.NET Web API 2 project to ASP.NET Core. While migrating I am unable to find this.Request object. Can anyone help me solve out this issue?
This question was asked here, but since ASP.NET Core was still probably in an RC state then, I figured I'd answer here instead of referring to there because there is some stuff that's obsolete or completely gone from the official release.
Assuming your controller class inherits from Controller (or more specifically, ControllerBase) then it does have a this.Request property as you can see here and here. As Pawel noted, you can also access it from the this.HttpContext property.
The request's URL is broken up into several properties on HttpRequest. You can access the URL in a friendlier API by adding using Microsoft.AspNetCore.Http.Extensions; which gets you access to the following extension methods:
GetDisplayUrl()
GetEncodedUrl()
As far as the query string, HttpRequest provides QueryString and Query properties for you to interact with.
Side note: I just created an app from scratch targeting ASP.NET Core on .NET Core for the first time on this laptop, and it took a while for the Intellisense to work for the Request property, so I'm wondering if that could have been your issue.
You need to override your class like this to get this.Request
public partial class _Default : System.Web.UI.Page
I am working on a Silverlight applicaiton. It uses WCF services to pass EF 4 Self Tracking Entities back and forth from client to server.
Read methods are working fine to serve the Trackable entity collections to the Silverlight client from the WCF services. Even basic updates are working correctly. I can modify a property of "OfficeEntity", and pass it as a parameter to a WCF update method.
The issue we are having is when we update one of the Entity's collections, we get the below deserialization error. For example, if "OfficeEntity" has a navigation property "Locations" that is a collection of "LocationEntity", and we add a new "Location" to the "Locations" property and save it, we get the deserialization exception.
officeEntity.Locations.Add(new Location() {LocationName = "Test 1"});
client.SaveAsync(officeEntity);
Exception Details:
The formatter threw an exception while trying to deserialize the message:
There was an error while trying to deserialize parameter :OfficeEntity. The InnerException >message was
'There was an error deserializing the object of type Entities.OfficeEntity.
End element 'ObjectsAddedToCollectionProperties' from namespace >'http://schemas.datacontract.org/2004/07/Entities' expected.
Found element 'b:AddedObjectsForProperty' from namespace >'http://schemas.datacontract.org/2004/07/Entities'.'
It appears the problem is with deserializing the change tracking properties. Any ideas on what causes this or where I can fix it?
Thanks,
Jason
Self tracking entities have issues with tracking if the actual generated entities aren't used in the client - I blogged about it here.
Not sure if this is at the root of your serialization issues but will definitely have an impact on you being able to use self-tracking entities
I have the following Ria Service define:
namespace SilverlightTest.Web
{
[EnableClientAccess()]
public class ContactService : LinqToEntitiesDomainService<AdventureWorksEntities>
{
public IQueryable<Contact> GetContactSearch(string lastName)
{
ContactRepository rep = new ContactRepository();
return rep.SearchByLastName(lastName);
}
}
}
When I compile the solution, my SilverlightTest project does create the SilverlightTest.Web.g.cs file and the appropriate Context objects are created when I look at it. However, when I attempt to import the SilverlightTest.Web namespace to access the Data Context class for the above service, it says it cannot find the Web namespace.
The only difference I can see between what I'm doing and many examples that are out there on the web is that my AdventureWorksEntities data context is located in a separate business object dll. I tried to query the context directly instead of using the Repository Pattern I'm attempting to do and it also isn't work working.
Any ideas? Is it possible to have Ria Services access a separate DLL handling data access or does it HAVE to be in the same project?
I've been able to put the Ria service in a separate project before, although I do remember having issues. Not sure exactly what it was, but I would check two things: your references and your web.config (in the hosting website). When you add a ria service to a web project it does some things behind the scenes that wire everything up correctly.
Could try adding a service to your web project temporarily and see what it adds.
It seems that Resharper does not recognize the .gs files and their name spaces. If you disable R# or just code without intelisense it works.
I have come across a bit of a problem while using Unity and WPF. The scenario is I have a WPF application which follows the MVVM design pattern. A have a module called ViewKDI. Within this module I have a service called ViewKDIService, the ViewKDIService service utilises another service called UserService.
Every time I load the module ViewKDI I want Unity to return me a new instance of both the ViewKDIService and the UserService.
I have put the below in the shell bootstrapper:
Container.RegisterType<IUserService, UserService>();
In the ViewKDI module I have put the following:
Container.RegisterType<IViewKDIService, ViewKDIService>();
Each time the ViewKDI module loads the ViewKDIService constructor is called. However the UserService constructor is only called the first time, this means that I am not getting a new instance of UserService.
I require unity to give me a new instance of UserService too so that I can manage this session separately from the rest of the application.
Any ideas?
Thanks
Faisal
Unity's default behaviour is to create a new instance of each object each time one is requested, so you shouldn't be seeing this behaviour.
From what I can gather from the source code and MSDN documentation (this is a good read), you can specify a "lifetime manager" object when you register a type to tell Unity how the type should be constructed and cached. Using the TransientLifetimeManager (which essentially does no caching) will cause Unity to re-create the class each time. So try this:
Container.RegisterType<IUserService, UserService>(new TransientLifetimeManager());
... and see if it creates a new UserService each time.