What I'm trying to accomplish is the following: I need to limit the amount of core data entries to 50. So if the user enters their 50th entry then the app would delete the oldest entry and add the new entry to the top of the stack. So basically, if the user never deletes entries and if there are 50 entries in core data then, when the user tries to add a new entry, the app would delete the oldest entry and add the user's new entry. Basically, I'm trying to have a history sort of thing but I don't want the user to be able to go past 50 entries however I want them to be able to add new entries when their at the 50 limit by just dropping the oldest one and adding the newest one. What would be the easiest way to do this? I'm new to core data and having a hard time understanding a lot of it. Here's the code / example app that I'm working with. LINK TO EXAMPLE APP THAT I'M USING Thanks for the help.
Let's say you have an entity called History. The easiest solution would be to add a creationDate attribute to your entities. Then use that to manage your History objects.
You will need three fetches:
The first one will fetch as faults all the existing History objects and then count them. If the count is <50, then just add the new History object and your done.
If the count>=50, then do a fetch for specific value and use the #max or #min (I forget which for dates) collections operator to find the oldest creationDate. (As luck would have it the example at the link it pretty much exactly what you need.)
Perform a fetch for the object with the creationDate returned by (2) and delete it.
Then add the new history object.
OK, that's fine. CoreData is not going to do this for you, but you can do it yourself.
You can retrieve objects from you context using an NSFetchRequest, and you can delete them using -[NSManagedObjectContext deleteObject:]. You can sort them using NSSortDescriptor objects.
Related
I started using django-simple-history in order to keep the history but when I delete an object (from admin page at least) I notice that it is gone for good.
I suppose I could create tags and "hide" objects instead of deleting in my views but would be nice if there is an easier way with django-simple-history, which would also cover admin operations.
When objects are deleted, that deletion is also recorded in history. The object does not exist anymore, but its history is safe.
If you browse your database, you should find a table named:
[app_name]_history[model_name]
It contains a line with the last state of the object. That line also contains additional columns: history_id, history_change_reason, history_date, history_type. For a deletion, history_type will be set to "-" (minus sign).
Knowing that, it is possible to revert a deletion programmatically, but not through the Django Admin. Have a look at django-simple-history documentation for details on how to do it programmatically.
Hope that helps!
A search on the PROJ object for updates seems to be capped at 20, even though more updates exist. Here is an example:
https : //[domain].attask-ondemand.com/attask/api/v4.0/proj/search?method=GET&fields=updates:styledMessage&ID=[guid]
Conversely, by searching the NOTE object using topNoteObjCode = PROJ and topObjID = [guid], all of the notes are retrieved.
Anyone know a trick to pull more (or ideally, all) of the updates via the PROJ object?
Regards,
Doug
I am working on something similar at the moment and it does not appear that it is possible to pull any more or less than 20 updates using the project->Updates collection. I suspect that is because this is a collection and you cannot pass arguments in.
For items like this I end up simply passing an array of ID's I'm looking for into the updates object as a "in" search against the refObjCode field. There is an unpublished number of ID's you can pass at a time. I think it is around 130, but I always batch it at 100.
It's a bit of a pain sorting the resulting list of updates back into the list of projects or tasks.
I have a collection with a bunch of documents representing various items. Once in a while, I need to update item properties, but the update takes some time. When properties are updated, the item gets a new timestamp for when it was modified. If I run updates one at a time, then there is no problem. However, if I want to run multiple update processes simultaneously, it's possible that one process starts updating the item, but the next process still sees the item as needing an update and starts updating it as well.
One solution is to mark the item as soon as it is retrieved for update (findAndModify), but it seems wasteful to add a whole extra field to every document just to keep track of items currently being updated.
This should be a very common issue. Maybe there are some built-in functions that exist to address it? If not, is there a standard established method to deal with it?
I apologize if this has been addressed before, but I am having a hard time finding this information. I may just be using the wrong terms.
You could use db.currentOp() to check if an update is already in flight.
First of all I want to show how I made this in SQL:
Both the location and environment table will never contain more than those four rows. Each log can only be associated with 4 rows.
What I don't understand is how do I even start writing code that will take whatever the user has chosen, based on state switches etc in my UI and persist this?
Because when the user are done I want to store a "log-record", and the log-record may have location and environment rows associated with it. And what happen when the user let say, choose all the location rows, four times a row....does it add the location to the location "entity" every time? Would I end up with a lot of duplicated data? I would appreciate any help that can show me how to do this. Thank you!
Looks like you need three entities. You'll have Location and Environment entities that have whichever attributes they need, and a Log entity that has relationship with both Environment and Location. I think you're asking if instances of Location and Environment that happen to be the same will be duplicated in the core data store, or if multiple Log instances will relate to the same Location and Environment instances. Is that right? Answer: It's up to you. Say you want to save a Location instance that has a particular set of attributes. You could first search for one that has that exact set of attributes and associate it with your Log instance, or you could just create a new Location instance and not worry about the duplication. If you're storing zillions of these Log entries, the first plan might save a lot of space. If you're not saving them all that often, and particularly if the user can go back and change the data associated with a Log instance, you might want to use separate instances even if they happen to be the same.
I have a medical app for the iPhone that I'm working on, where a user creates timestamped entries for a series of tests performed, which are stored in sqlite for retrieval and subsequent drilldown. In my model class, I have a property uses an NSArray that is populated with these entries, which gets updated as new additions are made in the app.
One thing I'd like to do is display UI behavior similiar to what the Calendar list view does - for any given day, display a section header, that show the name of the day and the date, ans display the entries made for that day.
From a brute force standpoint, I can see how you could precalculate this - as build your list of entries, you could store the entire list in a dictionary, keyed by date.
This seems pretty inelegant though, so I'm wondering if there are other more efficient ways to accomplish this task.
If Core Data WERE available on the iPhone, you could store your information that way instead of sqlite.
Then, when you wanted data for particular day you could search using NSPredicate with a sort descriptor.
Core Data will then return the relevant data sorted according to your descriptor. Nice and neat.
Maybe visit the Apple Dev Center/Forums for some more info on upcoming software...