Is it possible to add properties to my model that dont exist in the database?
For example I have a calendar table, I want to retireve this data in my MVC controller then work out time left until each entry starts and return this to the view. So I would like another property in my calendar model to hold time left which is a value that I will generate outside of the database.
I've tried just adding the property but when I do that I get errors because the property is not mapped to anything.
Is this even possible?
Thanks
You should be able to add the property to the Model but you will not be able to query it with LINQ. LINQ will ultimately build and expression which it will want to run against the database using SQL. Its at that point that your LINQ will fail to find a mapping from your property to a field somewhere.
If your query returns an IEnumerable of the actual type on which you have created the property your view may be able to access it. I can't remember if EF insists on mapping in that case, it may do.
You might find that you can create subsequent LINQ query that uses LINQ-to-objects if you want to provide some other composite type to your view.
It's a non-persistent property or transient. I don't know Entity Framwork well but with a quick google search you should find the answer.
BTW you can find a lot of tips here :
http://weblogs.asp.net/zeeshanhirani/archive/2008/12/18/my-christmas-present-to-the-entity-framework-community.aspx
After making a quick search myself and a test in VS2008 I don't see a way to exclude a property from the mapping. Maybe it requires you to edit manually the mapping file ? :(
Related
I'm new to infragistics. I have a database and a datalayer with entity framework and linq. Now I want to get the data to an Infragisticscontrol, let's use a UltraCombo. I have not problem to bind the data to the control. My problem is that all properties from the linqquery is displayed.
As far as I can see there are two options
1) Create a data schema manually. In this way there is much effort put in creating the schema and when I refactor something then the schemas of all controls must be updated.
2) Creating a data schema automatically.
I played a bit with the secand case but can'T find an option how to create the data schema automatically but binding the data manually. I had one case where I bound it to a model of the entity framework and deleted the datasource later from the project. In this case it worked but I don't think that this is the right way to use it.
Can somebody tell me how to do this or what's the best practice?
I found a solution in the Infragistics forum below. Here's the link: http://blogs.infragistics.com/forums/p/24379/89509.aspx
I have the following scenario:
My website db has a system table called "Companies", which includes an id field, companyName field, and companyImageUrl field.
How do I set up an umbraco document type for adding entries to this table ?
Maybe I shouldn't use a custom table at all ?
Thanks.
As far as I know, Umbraco doesn't support what you want to do out of the box (mapping a document type to a table that isn't part of the umbraco core).
One approach that might work is to create an action handler that syncs a Company doc type to your table when creating a node of that type.
It's a bit of a hack though. I've found that I've very rarely needed to create custom tables. What exactly are you trying to do with it? My guess is that you don't really need it and would be better off working with a doc type instead. Umbraco provides a variety of ways to get and act upon doc types from within custom C# code (check out the umbraco.NodeFactory namespace). You'll also get the added benefit of being able to easily interact with these nodes from XSLT/Razor.
How do I define a database view using Entity Framework 4 Code-First? I can't find anything about this anywhere!
That's because you cannot define database view using code-first approach. Database view is database construct which uses SQL Query on top of existing tables / functions. You can't define such constructs using code first.
If you want view you must create it manually by executing CREATE VIEW SQL script for example in custom initializer - it will be similar like this answer. Just be aware that this will not help you if you want to map entity to a view. In such case you would probably have to first drop table created by EF and create view with the same name (I didn't try it but it could do the trick). Also be aware that not every view is udpatable so you will most probably get read only entity.
To do a view you create the model, then in the initializer you run the SQL statement to create the view directly against the context with the first line of code, and then in the context you override OnModelCreating and run the second line of code to ignore the model.
context.Database.ExecuteSqlCommand(Resources.<resourcename>);
modelBuilder.Ignore<modeltype>();
I have an application with user and admin sections. If an admin updates data with the help of sql datasource then it's updated the database. However, when we retrieve data with linq query then it's showing its old value rather than the updated value.
After some time, the linq query automatically shows the correct value.
I think its caching the value, but I find myself helpless. Please help me with this.
When you say
when we retrieve data with linq query
Do you mean you call your select methods again or are you using the current in memory objects?
In either case, you can always refresh an entity with :
Context.Refresh(System.Data.Linq.RefreshMode.OverwriteCurrentValues, entity)
Make sure that you're using your DataContext efficiently (ideally one per unit of work).
After each update, make sure you call DataContext.SubmitChanges(); to commit your changes back to the database.
Also be aware that any context you instanciate between your changes being added to another context and calling SubmitChanges() will not reflect those changes.
Often I need to combine data from multiple tables and display the result in a GridView control.
I can write a Linq query inline in the Page_load event, return an anonymous type that combines all the fields that I need, and databind the result to the GridView control.
Problem: I use 'helper methods' as described by Scott Guthrie on his blog. Such a helper method cannot return an anonymous type. The query would have to be inline for this approach.
I can write a database view that returns the data that I need, and write a helper method with a query against this (new and known) type that it returns.
Problem: I will need a lot of views in my database schema, and I will introduce a lot of redundant aspects of my data. I also lose some of the advantage of using Linq - removing all business logic from the database.
I would like to take an approach that lets me keep the Linq queries in helper methods, yet allows me to access all the attributes that I need on the grid in their respective databinding expressions. Can this be done?
I asked the wrong question, as I frequently do. What prompted me to look into anonymous types was an apparent limitation of the GridView - my inability to use a databinding expression in an <asp:BoundField> (the DataField parameter only accepts column names of the table that the Linq query pulls in).
Turns out that in a TemplateField it is possible to use Eval and access members of the Linq data item, and Linq takes care of the query for me.
In other words, I can keep the query in my helper method, have it return a primary database table type (e.g. Account), and I bind the Accounts to the GridView.
In the databinding expressions I can access data members of the Account objects that reside in other tables, without having to explicitly pull them in in the query. Perfect.
I don't know if there is a viable way to achieve this using anonymous types. But I have a suggestion that will work in WinForms, but I am not sure about ASP.NET.
What you need is a type with properties where neither the number of properties, nor the types and names of the properties are known at compile time. One way to create such a thing is ICustomTypeDescriptor.
You have to create a type implementing this interface with an private backing store of objects backing the properties returned by the query for one row from the query. Then you implement GetProperties() to return one PropertyDescriptor per column and PropertyDescriptor.GetValue() and PropertyDescriptor.SetValue() to access the backing array.
By implementing PropertyDescriptor.Name you will get the correct column name; this will probably require another backing store storing the property names. And there is a lot more to implement, but in the end your new type will behave almost like a normal type - and now the if - if the control you are binding to knows about and uses ICustomTypeDescriptor.
UPDATE
I just found an bit of text stating that ASP.NET data binding knows and uses ICustomTypeDescriptor.
Scott's earlier post in the series talks about shaping the result set before inserting into a grid:
Part 3 - Querying our Database
Scroll down to "Shaping our Query Results".