At the time of saving the session, [aerospike express session store][1] stringifies the object and saves it in one bin (named session). I want to save some of the data in separate bin so that I can create a secondary index on them? Any way to do that?
It's unfortunately not possible at the moment. But maybe we can work out a solution via the Github issue you filed for the aerospike-session-store module.
Related
Somehow I found some of the repositories(physics_base for example) in workbench are missing, but when I searched into the data path /.aduna/openrdf-sesame/repositories/physics_base, I found the data still exist.
So does this mean that there is a way to recover my data in workbench?
Thank you for any suggestion.
Yes that's possible. Just create a new repository of the same type in the workbench, open it once, shut down sesame, then copy over the contents of the directory to the data directory of your new repository.
It might even be possible to just create a repository of the same name and have it automatically pick up the existing data, but I can't test that right now (in a pub), so if you want to try that, make a backup first.
I currently have one container which runs Crate, and stores all its data in the /data/ directory. I am trying to create a clone of this container for debugging purposes -- ideally, the clone would be running Crate (which I can query) using the exact same data. I've tried mounting the same data directory into the /data/ directory of the cloned container and starting Crate, but when I run any queries, I notice that Crate shows 0 tables (that is, it doesn't recognize the data in the folder as database tables). How do I get around this? I know I can export and import data using COPY TO and COPY FROM, but I have so many tables that that would be quite cumbersome to write.
I’m a little bit wondering why you want to use the same data directory for debugging purposes, since you then modify data, which you probably don’t want to change. Also, the two instances would overwrite each others data, when using the same data directory at the same time. That’s the reason why this is not working.
What you still can do, is simply copying the folder in your file system and mount the second debugging node to the cloned folder.
Another solution would be to create a cluster containing both nodes as documented here: https://crate.io/docs/crate/guide/best_practices/docker.html.
Hope that helps.
I want to create a large database. I am thinking of using core data for this purpose.But i want to insert the data to it manually and only once. This data is never deleted or edited but only read. How can i use core data to add such large number of objects to database? How to create database in core data and write only once.
Your question is quite general but I'll try to give you some hints on it.
Based on my experience, the simplest way to achieve it, it's to follow these two steps:
1) You could create an external file, in XML, JSON or plist format, that you can parse and use to create a prepulated a Core Data store. You can find some info in core-data-tutorial-how-to-preloadimport-existing-data-updated. In particular, you could set up a dummy project (or just use the AppDelegate methods) and use it to create the store, e.g. MyDataStore.sqlite.
2) Once you created, forget about the routines you have previously used and you ship the store in the application's bundle of your app. There the store is read-only. Otherwise, if you need to modify it, you are not allowed to do it and so you need to move it, for example, to the document directory.
You cand find additional info in the following SO topics:
Is Core Data useful for readonly data too?
How can I ship my app with a pre-populated Core Data database?
Core Data Store included in App Bundle
P.S. If you are in production and you need to make same change to your store, you need to republish the app (since the store is within the main bundle). To avoid this you need to move the store to a different directory and set up, for example, a sort of sync mechanism.
Hope that helps.
I have a mosques database that has 1000 items ..
I want to use Core Data approach in accessing my database ..
I have already tried the SQLite approach to create the database
where I have a text Pad file with all data seperated by tabs
and then Import the data from txt file to sql file ..
Now this works fine ..
I want to know how can I import data from my SQL file to the newly created Core Data Project
Shall I add SQL file to resources ??
Copy it or not ??
I have looked at CoreDataBooks example but I think I'm missing something
I want to know the exact way for adding an SQL file to the resources of a Core Data Project ..
You can't.
You should regard the fact that Core Data uses SQLite as the format to save the file as an implementation detail, not to be used directly unless you really, really, really need to do that. For example, you can't expect Core Data to work alright if you also directly writes on to the SQLite file.
Instead, read the Core Data documentation, and import the data directly from the tab-separated text file to the Core Data context, and let the Core Data save it to the file. Yes it does use SQLite behind the scenes, but it's better for you to forget that fact.
Yuji and Dave DeLong are right on both accounts, however I feel like I should add that just because you can't realistically feed CoreData a pre-populated SQLite file doesn't mean you can't bootstrap your CoreData store from a SQLite file (or a text file or anything else.) It just means that you have to do the work yourself.
For instance, you could include your pre-populated SQLite file (with it's own, non-CoreData schema, etc) as a resource in the project. Then when your app starts up, if it sees that the CoreData store is empty, you can use the SQLite API directly to open/query your bootstrapping database and translate the results into operations that generate the desired object graph in CoreData. The next time the app starts up, the CoreData object graph will be populated, and you won't have to do it again.
The take away here is that while it's not "free," it's not "impossible." Many, many apps include built-in CoreData repositories that contain data. That data had to be bootstrapped from somewhere, right?
I just started playing with the Azure Library for Lucene.NET (http://code.msdn.microsoft.com/AzureDirectory). Until now, I was using my own custom code for writing lucene indexes on the azure blob. So, I was copying the blob to localstorage of the azure web/worker role and reading/writing docs to the index. I was using my custom locking mechanism to make sure we dont have clashes between reads and writes to the blob. I am hoping Azure Library would take care of these issues for me.
However, while trying out the test app, I tweaked the code to use compound-file option, and that created a new file everytime I wrote to the index. Now, my question is, if I have to maintain the index - i.e keep a snapshot of the index file and use it if the main index gets corrupt, then how do I go about doing this. Should I keep a backup of all the .cfs files that are created or handling only the latest one is fine. Are there api calls to clean up the blob to keep the latest file after each write to the index?
Thanks
Kapil
After i answered this, we ended up changing our search infrastructure and used Windows Azure Drive. We had a Worker Role, which would mount a VHD using the Block Storage, and host the Lucene.NET Index on it. The code checked to make sure the VHD was mounted first and that the index directory existed. If the worker role fell over, the VHD would automatically dismount after 60 seconds, and a second worker role could pick it up.
We have since changed our infrastructure again and moved to Amazon with a Solr instance for search, but the VHD option worked well during development. it could have worked well in Test and Production, but Requirements meant we needed to move to EC2.
i am using AzureDirectory for Full Text indexing on Azure, and i am getting some odd results also... but hopefully this answer will be of some use to you...
firstly, the compound-file option: from what i am reading and figuring out, the compound file is a single large file with all the index data inside. the alliterative to this is having lots of smaller files (configured using the SetMaxMergeDocs(int) function of IndexWriter) written to storage. the problem with this is once you get to lots of files (i foolishly set this to about 5000) it takes an age to download the indexes (On the Azure server it takes about a minute,, of my dev box... well its been running for 20 min now and still not finished...).
as for backing up indexes, i have not come up against this yet, but given we have about 5 million records currently, and that will grow, i am wondering about this also. if you are using a single compounded file, maybe downloading the files to a worker role, zipping them and uploading them with todays date would work... if you have a smaller set of documents, you might get away with re-indexing the data if something goes wrong... but again, depends on the number....