I use CoreData for storing images. Often these images are the same.
I use bindings to setup a table view. One column contains the images.
Now I don't always want to store the whole image data. I just want to store the path to the image, but still display the images in the table view.
What's the best way to do so? I can' figure it out.
You can store a string and required metadata for each one. If you are worried about name conflicts, rename the files as unique identifiers and store the file's real name or title in the database in a second column. The biggest risk is the file system going out of sync with the database representation, so be careful to check for errors and to handle them appropriately, for example, if the image row can't be deleted, you shouldn't delete the file and vice versa.
Related
I have a data structure (B-Tree) that stores text as a series of nodes each one representing a single line of the text. I would like to store the text in a file that I could keep in sync with the structure without having to rewrite the entire file on each edit. So when line n of my structure is changed I can access and change only line n of the file keeping it updated with the structure.
Can someone point me in the right direction?
The reason for this is I'm trying to store the state of my structure so I can restore after a crash, but without the overhead of constantly writing the entire file. (Could be a lot of data)
Looks like you want a B-Tree.
If you go this route, keep in mind all relational databases are built on B-Trees. So you may consider using some embedded database, like SQLite, instead.
I'm wrinting a very simple application which can read data from a specified file and populate the fetched data to a NSTableView. The file is a plain text file where each line represents an object (I need to parse the file). I want to use Core Data and my question is what is the Cocoa way to do that?
My first idea is to parse the file and create instances for the Entity which represents one line. I'm not sure that is it the best solution. And later I'll write out the changes to the file (after save? or automatically after a given amount of time?)
My configuration is Mountain Lion and the latest XCode.
A single entity with a number of attributes sounds good. If you had an attribute which holds a reasonable amount of data and was repeated on a number of 'rows' then it would be a candidate for another entity.
Yes, each instance of your entity would represent one row in your table.
Personally, I would either save on request by the user, or not have a save button and save each change. Your issue is the conversion between your in-memory store and on-disk store. Using a plain text file doesn't help (though, depending on the file format, it could be possible to edit individual lines in the file using NSFileHandle).
Generally it would still make more sense to use a better format like XML or JSON and then make use of a framework like RestKit which will do all of the parsing and mapping for you (after you specify the mapping configuration).
You can also use bindings to connect your data to your NSTableView. Another ref.
Usually I populate my core data with data from internet.
But say I want to prepopulate it with data without downloading it from internet.
Say I want to store all cities, or all tags first.
What would be the standard way to do so?
Should I store the cities on plist?
Should I hardcode inserting all data?
Should I set a variable in coredata to tell whether it has been initialized or not?
What do you guys do?
If it's a lot of data, the fastest way is to provide a populated store. Assuming you're using a sqlite database, you can simply use the Simulator to generate it once, and then put that in your app.
If it's a small amount of data, I'd insert the data at first start, while reading it from some form of xml, csv, or even hardcoded (script-generated) insert statements. It all depends on the situation.
When using Core Data not read-only, you should copy the database to a place where you're allowed to write, when the app starts for the first time. In a read only situation, you can just use the database from the bundle.
The templates for these HTML emails are all the same, but there are just different variables for say, first name, last name and such.
Would it just make sense to store the most minimal of data that I need, and load the template in and replace the variables everytime?
Another option would be to actually create the HTML file and store a reference to it, which probably would be the easiest to do except it might be a pain managing the files, and it adds complexity in regards to migrating, file permissions, et cetera.
Looking for opinions from people who've done this before...
GOAL/PURPOSE/USE:
I have a booking engine. When users make a booking, they are sent a confirmation email, generated from the sessionized booking data.
This email provides a "Cannot view this email? See it here" link which provides a web view of the email, in addition to a plaintext view.
I need to display the same email that was sent out, in addition to the plaintext view.
The template is subject to change, but I think because of that very fact I should have a table of templates and map the data to a template.
That's what I would do, because the template layout may change over the time, but the person information should remain the same. So, it makes sense to just store the person information in the database and leave the template out from the database.
In fact, it would be even better if you use template engine such as Velocity (in Java) to construct your HTML emails... very easy, by the way.
On the one hand cpu is more expensive then memory, so mostly it is better to save more data to reduce cpu power used by computation.
But in your case, I would save the minimal data, the emails or what you are tying to save, because it allows you to easily remodel your templates, and to reuse the data at multiple places of your application.
You persist redundant data (especially because of the template) which is in no way normalized. I would not suggest to do that. But mentioned in the comment it is important what you want to do with that data.
If you only save the data you need you could for example exchange that template easy and use another one.
Yea, your right on track. I did a similar thing. All dynamic/runtime variables were starting from ##symbol.
So in database you would have one Template table. One table would be for dynamic/runtime variables. One table for Mapping between Template and dynamic/runtime variables.
tblTemplate - TemplateID, TemplateValue
tblRuntimeVariables - RuntimeVariableID, VariableString, VariableSQL
tblMapping - TemplateID, RuntimeVariableID, RuntimeVariableValue
Advantage of using an extra mapping table is that on adding new dynamic variables to existing change would mean making no change to existing database. Only more rows would be added to tblMapping.
In my case I was also having one extra column for storing SQL Statements in tblRuntimeVariables in case the value for a runtime variable is fetched from database.
I think read somewhere that when a View is requested the "map" is only run across documents that have been added since the last time it was requested? How is this determined? I thought I saw something about a sequence number. Is this something that you can get to? Its not part of the UUID trailing on the _rev field is it?
Any way to force a 'recalc' of the entire View (across all records)?
The section about View Indexes in the Technical Overview is a great guide to this.
The view builder uses the database sequence ID to determine if the view group is fully up-to-date with the database. If not, the view engine examines the all database documents (in packed sequential order) changed since the last refresh. Documents are read in the order they occur in the disk file, reducing the frequency and cost of disk head seeks.
As documents are examined, their previous row values are removed from the view indexes, if they exist. If the document is selected by a view function, the function results are inserted into the view as a new row.
CouchDB first checks to see if anything has changed in the entire database using a sequence id (that gets updated whenever there's a change to any document in the database). If something has changed it goes looking for those documents and runs the map function on them.
There really shouldn't be any need to rebuild/regenerate your views since it will incrementally refresh as you modify your documents (note that it won't update the view until you use it though). With hat said one way (and I'm sure there's a better way) would be to remove the design document describing the view and insert it again seeing as a design document is no different (almost) from a normal document.