This sounds very simple however I cant seem to find a answer, how do you map a view to a model in datamapper? If I remove the ID field which my view doesnt have, datamapper complains, if I leave it there then everytime I execute a select it says my column id doesnt exist, because it's a view not a table.
DataMapper 1.x does not have native support for views. It expects models to have at least one property that acts as the primary key.
This primary key will normally be used for specifying updates and lazy attribute loads.
When your view does have a column with unique values just specify :key => true in the property options that belong to this column.
No need to specify a property with the name :id.
When you do not have a column with unique value, use a compound primary key (CPK). A set of columns that form a unique combination of values:
class ModelFromView
include DataMapper::Resource
property :key_like_property_a, String, :key => true
property :key_like_property_b, Integer, :key => true
property :other_property, Integer
...
end
Related
I am developing a web app on an existing database which unfortunately I cannot change.
I get this error
"More than one property map found for property 'Id' when using case-insensitive search. "
After a little search I found that the problem is that there are some conventions in EF and more specifically one that states (according to what I read here) that:
if the field name contains a suffix of ID (case-insensitive), then EF will automatically include it as a primary key
The table has already a primary key (named 'id').
Is there a way to disable the EF conventions or in any other way to allow having besides my 'id' field, a field named "something_id" without getting this error?
this is how to disable the id convention of EF:
inside OnModelCreating
modelBuilder.Conventions.Remove<IdKeyDiscoveryConvention>();
I do NOT have config.active_record.whitelist_attributes = true in application config. And I have attr_protected() in the model class. However, I notice that the id and type attributes are automatically inserted into ActiveModel::MassAssignmentSecurity::BlackList. This makes sense for id attribute since we do not want to set id in a mass assignment, but why this is also true for the type attribute?
The attribute type is used by active record when you are using single table inheritance between active record models, that's why it's in the black list. It holds the name of the class that was saved so Rails knows what kind of object was saved.
Given a table with fields like title, title_sp, title_jp, and knowing a particular language value for a user (like jp), what would be a method by which to remap table fields to model attributes at runtime. Something like setting alias_attribute on a per invocation basis in find(*args).
Something along the lines of:
Posts.find(:all, :conditions => {:published => true}, :language => "jp")
and have the returned Posts.title be populated by the value in title_jp. added ideal pointer would also have it able to fall back to title/title_en if title_jp is nil/empty.
I've been digging around overriding .find, but not able to sort out how to bulk remap the field names.
It is dangerous to do such thing. You are able to do this with some find_by_sql, but if you persist the object back, you will propably alter the original title, because the model won't know, that it is not the original value.
The better solution is to create a virtual attribute, which selects the best column to return, based on the parameter. It may be a bit problematic to use, but it is much more safer this way. It is not so hard to write a wrapper, so a whole collection can be accessed with a single call, and setting the virtual attribute in each to the right value.
If you have more than one field to override, you can write a small solution to create a virtual attribute to each. If you need more on this, just let me know!
Quick question that requires a long explanation..
Say I have two tables - one is an item table (say 'Users') and another is a definition table - like 'Custom Properties'. Many different items in the system ('Users', 'Articles', 'Posts', etc) can all have custom property defined to them, and these are stored in the 'Custom Properties' table. So, for example, the 'Custom Properties' table looks like:
CREATE TABLE [CUSTOMPROP_DEFINITION] (
[ITEM_TYPE] INTEGER NOT NULL,
[POSITION] INTEGER NOT NULL,
[NAME] NVARCHAR(MAX) NOT NULL
)
Simple little table. Each item has a 'item_type' id (for example, a user is an item type of 1. Article would be an item type of 2, and so on), so this table could have multiple rows for each item. Essentially, this table's metadata for the other tables.
I want to create a navigation property on my Users table, that will link to all the entries in the props table where 'item_type' == 1.
What's the best way of going about this? From the way I see it, there are two options -
(1) Creating a navigation property through the EDMX and letting it populate it automagically. (This is preferred, but having troubles implementing..) or
(2) Creating a property in the partial class, and having that load everything manually.
The issue with #2 is that it would (could potentially?) be slower than having the entity framework handle loading.
The issue with #1 is that.. no matter what I try, I can't get a NavigationProperty defined that will handle it. Because the primary key is a fixed number - i.e. It will always be '1' for ALL Users, always be '2' for all articles, etc.. - I haven't been able to find a way to hook into that.
Thoughts?
--Mike.
What you're describing isn't really a "Navigation Property" in terms of what EF defines as a naviation property. A navigation property in EF terms follows a [usually] primary key - foreign key reference in the database schema itself. And, AFAIK, the only way to get that navigation property in the EDMX is for there to actually be a FK involved.
You could, obviously (and probably do) have a FK here, but that's not entirely what you want, because that FK is going to return all instances of your custom properties for the given primary key. What you want is instances of only a particular type; and I don't think there is a "off the shelf" way of doing this in EF.
What you probably want to do is implement a Stored Procedure, and bring that into your model; you could then implement this is a property (or probably more appropriately a method) on your entity.
Alternatively, you could just create the FK, have your entity load all of the custom properties, and then write "helper properties" that do simple LINQ based .Where() filters.
I am looking for a better way to implement following situation...
A group has_many users. When creating group I want to add different types users at same time.
If user type selected (from dropdown) is 'Salesperson' then I have to fill his/her earnings (year, earning).
If user type selected is 'Supervisor' then I just have to fill his/her email.
If user type is 'Bot' then nothing needs to be filled.
Right-now I am just showing respective fields and storing hidden (other types' data) simply null using nested forms.
I am sure there's a better way, I just need a lead.
One option is to store the different types of users in different tables (salespeople, supervisors and bots) so that you don't need to pass the additional attributes as all.
If you are using a single table, then you can also set default values for attributes to nil so that you don't need to explicitly pass nil to the attributes when you don't want to set them:
add_column :users, :salary, :float, :default => nil
NOTE: In MySQL the default will be NULL, so you don't need to explicitly specify this in your migrations.