I have a static table for settings where I want to pull some stuff from an entity in Core Data. The use case does not lend itself to a table of records as you usually see. Rather each row of the static table is really a field related to the user--as in a user profile. I have a feeling that in testing I may have created more than one record in the entity. I know there are programs that let you see the SQL lite database underneath, but my question assumes you do not have this tool and are relying just on Xcode.
My question is when you have more than one record in a Core Data entity/table, and you try to load data from the managed object context into a VC, one field into one element, what record is shown by default?
Related to this, if you don't know how many managed object or rows are in the database, is there anyway to specify which record you want since there are no auto ids as you would use in a traditional database?
The record that gets loaded from the fetch first. Depending on your sort that might be consistent or it might be random.
Is it possible to recreate a database view using a migration? Migration that was used to create a view on database is no more as per the changes done in some table structures. How do I recreate a view as per the new design? Do I have to drop the existing view and create a new through the migration? Or is there a simpler way without losing data?
If you're talking about a view stored in the database, the usual technique in Rails would be not to do that but use scopes in your ActiveModel instead. This next statement is more with MySQL specifically in mind, but probably true generally: as long as you have the indices properly set up, that approach should be as fast as having a view in the database itself and be more programmatically easy to work with. You can specify calc'd fields in a scope through SQL statements if appropriate, though the usual response to that idea is why not have that be an accessor function in your model (as if it were in the database).
Does this help or am I answering a different question than you had?
I need to write a form for creating a new entity and with it, up to 3 relations (which are new entities).
I can either have it dynamically attach/delete them dynamically (which could be useful) or have all 3 always be related to the entity, and for them to have an 'active' boolean on them, which would be just as appropriate.
At what point should I be doing this? I need them rendered as checkboxes on the form.
So far I've tried attaching them to the entity prior to passing it to the form, but choice fields can't be passed unmapped entities, so that's no good.
I've also tinkered with a DataTransformer for this, although then, as far as I can see, I would have to create new entities in the DataTransformer, which seems wrong, and I can't get to work anyway- I don't have access to the entity within it and even hacking around that, the relationship fails to bind properly (Doctrine tries to save the relationships first).
In Symfony1 terms, I could just embed a couple of forms for each additional relation I needed, using new objects, and it'd just work, so surely there's still a relatively easy way around this?
A friend also recommended looking into the ResizeFormEventListener, but this, as far as I understand, is for 'resizing' a form based on the returned data, whilst I never want the form to change, I want 3 checkboxes always.
What's the best way to approach this problem?
I'm not sure on exact details without playing with it - but based on how i've done similar things, i'd be looking to use a 'collectiontype' and then adding the three department types into that.
What should I do if I have a Model which properties have to be filled from multiple tables from the EDMX file?
Should the Controller or specific actions do this work for me? Or is EF the wrong technology in this case because I [maybe] have to execute multiple statements to built a single model object for my view?
Update: Why is nobody mentioning ViewModels? I think this is the way to go? http://jabbr.net/#/rooms/aspnetmvc - One of the guys told me that it´s a standard approach to build a model from multiple entities from the db. So I´ll accept that?! Can anyone please give me a last "OK" on that? I think all this stuff has confused me because my mind wasn´t clear about the term "Model". I doesn´t have to be a 1:1 relationship and what I´m actually working with are VIEWmodels... right?
Code First approach. This way you control how the db maps to your model.
I ended up creating ViewModel classes.
I am quite sure I've seen the answer to this question somewhere, but as I couldn't find it with a couple of searches on SO or google, I ask it again anyway...
In Entity Framework, the only way to delete a data object seems to be
MyEntityModel ent = new MyEntityModel();
ent.DeleteObject(theObjectToDelete);
ent.SaveChanges();
However, this approach requires the object to be loaded to, in this case, the Controller first, just to delete it. Is there a way to delete a business object referencing only for instance its ID?
If there is a smarter way using Linq or Lambda expressions, that is fine too. The main objective, though, is to avoid loading data just to delete it.
It is worth knowing that the Entity Framework supports both to Linq to Entities and Entity SQL. If you find yourself wanting to do deletes or updates that could potentially affect many records you can use the equivalent of ExecuteNonQuery.
In Entity SQL this might look like
Using db As New HelloEfEntities
Dim qStr = "Delete " & _
"FROM Employee"
db.ExecuteStoreCommand(qStr)
db.SaveChanges()
End Using
In this example, db is my ObjectContext. Also note that the ExecuteStoreCommand function takes an optional array of parameters.
I found this post, which states that there really is no better way to delete records. The explanation given was that all the foreign keys, relations etc that are unique for this record are also deleted, and so EF needs to have the correct information about the record. I am puzzled by why this couldn't be achieved without loading data back and forth, but as it's not going to happen very often I have decided (for now) that I won't bother.
If you do have a solution to this problem, feel free to let me know =)
Apologies in advance, but I have to question your goal.
If you delete an object without ever reading it, then you can't know if another user has changed the object in between the time you confirmed that you wanted to delete the object and the actual delete. In "plain old SQL", this would be like doing:
DELETE FROM FOO
WHERE ID = 1234
Of course, most people don't actually do this. Instead, they do something like:
DELETE FROM FOO
WHERE ID = 1234
AND NAME = ?ExpectedName AND...
The point is that the delete should fail (do nothing) if another user has changed the record in the interim.
With this, better statement of the problem, there are two possible solutions when using the Entity Framework.
In your Delete method, the existing instance, compare the expected values of the properties, and delete if they are the same. In this case, the Entity Framework will take care of writing a DELETE statement which includes the property values.
Write a stored procedure which accepts both the IDE and the other property values, and execute that.
There's a way to spoof load an entity by re-calculating it's EntityKey. It looks like a bit of a hack, but might be the only way to do this in EF.
Blog article on Deleting without Fetching
You can create an object with the same id and pass it through to the delete
BUT its good for simple objects if you have complex relations you may need more than that
var user = new User { ID = 15 };
context.Entry(user).State = EntityState.Deleted;
context.SaveChanges();
var toDelete = new MyEntityModel{
GUID = guid,
//or ID = id, depending on the key
};
Db.MyEntityModels.Attach(toDelete);
Db.MyEntityModels.DeleteObject(toDelete);
Db.SaveChanges();
In case your key contains multiple columns, you need to provide all values (e.g. GUID, columnX, columnY etc).
Have also a look here for a generic function if you feel for something fancy.
With Entity Framework 5 there is Entity Framework Extended Library. Available on NuGet. Then you can write something like:
context.Users.Delete(u => u.Id == id);
It is also useful for bulk deletes.