This is my first time that I am working on a big project for a client. So I was not sure how to solve this problem. However I have come up with two different ideas but I need professionals opinion about which one is better :)
Situation :
There is an application which runs on different client's iPad. Application data is stored by using giant XML file. This XML file is shared among all client by a server. So a server has a centralised copy and each client has their own copy. Once client made changes to their XML copy they updates server copy in and other client updates their copy by updated server copy.
Now only one client can make changes at one time, To fix this I have logic by which before client starts editing XML they need to get ownership from server and server will only allow one client to edit at one time.
Visual Representation :
Now on client side I have to think of a logic by which I will update my client copy and upload it to server. There are two options,
Option 1 :
In option 1, I can directly manipulate XML file by using GDataXML parser and upload that copy to server. For persistence I can save client copy on my iPad in document directory.
Option 2 :
In option 2, I can read XML file create a CoreData representation for local storage. When ever I update data inside core data it will I will change XML file too and than upload that file on server. Double work but I guess better persistence.
Now which one more robust and advisable? Personally I was planning to do option 2 because it seems more robust as I am persisting application data in core data. But option 1 seems more easy work but I don't know how good persistency will remain.
Sorry for lengthy question,
Thanks for any input given.
There are a number of factors which would influence selecting the second option over the first.
How big is the XML file? If you need to work with very large documents, you may need to incrementally parse the XML (SAX) into core data. This will allow you to access the document's contents without loading it all into memory at once.
Do you need to run complex queries in the data? If so, you may be better off using core data fetch predicates, rather than xpath or XSL.
Are you already using core data? Depending on how the XML data is structured, it might be simpler overall to import the data into your existing persistent store.
Otherwise, you can probably make due with parsing the entire document and either traversing the resulting tree or querying with xpath.
If you need to create an object graph based on what you get from server and show it to user (which you most probably need to do), you should stick up to second option, since it allows easy and robust data persistence.
If you do not need to present user with any data from the XML file you can, of course, store it in the Documents directory.
So, if this is a client application and it has at least some visual representation of the data from an XML file you should use CoreData.
If you want a regular update of data , then use CoreData
Related
I have a task to do. I need to build a WCF service that allow a client to import a file inside a database using the server backend. In order to do this, i need to communicate to the server, the setting, the events needed to start and set the importation and most importantly the file to import. Now the problem is that these files can be extremely large (much bigger then 2gb), so it's not possible to send them via browser as they are. The only thing that comes into my mind is to split these files and send them one by one to the server.
I have also another requirement: i need to be 100% sure that this file are not corrupted, so i need to implement also a sort of policy for correction and possibly recover of the errors.
Do you know if there is a sort of API or dll that can help me to achieve my goals or is it better to write the code by myself? And in this case, which would be the optimal size of the packets?
I am building a Java app that uses an SQLite database to hold most of its data. For the end-user, the database would be almost entirely read-only, with very occasional edits. I'll (theoretically) be displaying/distributing it through my GitHub page, so my question is:
What's the best way to load the database into GitHub? (I'm using IntelliJ with DataGrip.)
I'd prefer to be able to update the database when I commit/push, instead of having to overwrite the whole file. The closest question I can find is How to include MySQL database schema on GitHub? but there could potentially be hundreds or thousands of entries, so I can't just rebuild the tables when the user installs the app.
I'm applying for entry-level developer jobs, and this project is going to be my main portfolio piece during job-hunting. I'm trying to make sure it is not only functional but also makes a good impression. Any help is (very) greatly appreciated.
EDIT:
After moving my .db file into the folder connected to GitHub (same level as my src folder) apparently I can now commit/push it with the rest of my files. How do I make sure that the connection from my Java code to the database stays valid once it is loaded onto another user's system? Can I just stick with
connection = DriverManager.getConnection("jdbc:sqlite:mydatabase.db");
or do I need to rework the path?
Upon starting, if your application can't find a corresponding sqlite database file, have it create one. Then do initial load of your tables from either CSV, JSON or XML files.
You can upload these files to Git, as they are text formats.
Let me explain in more detail:
1st: I'm running endeca 3.1, so Endeca Server here refers to 3.0's Data Domain.
I'm required to use an Endeca Server currently present on Endeca (Downloaded a Demo VM). All the info on it, including, groups, attributes and data, must be merged into out Endeca Server. (It can also be the other way around, i could merge my Endeca Server into this one.)
So far, i've tried to do the following:
1) Clone the Endeca Server
2) use the putCollection sconfig operation to create a collection on it with the same name i have on mine.
3) Load configurations using the LoadCollection & LoadAttributes graphs from OEID POC Template 3.1. I point to the new collection on the Configuration.xls file.
This is where i encounter an issue. The LoadAttributes graph gets a T/O message from the server's WS. Then the config WSDL becomes inaccesible for a while. I can't go beyond this point.
I've been able to load data into the collection, but i need to load the attributes first.
THanks in advance for your replies.
Regards
There are a few techniques.
Have you tried exporting the data domain and then importing it?
You can use the endeca-cmd tools to export to a file, and then import from that file. This would enable you to add 2 datastores into one server.
If you want to combine 2 datastores then that is a different question.
The simplest approach in 3.1 if the data collections are small. Extract then as CSV (via a data-table), convert to XLS and add them via self provisioning into separate collections within a single data store. If you are running in the VM this is potentially the easiest approach.
This can also be done using Integrator.
You don't need to load the attributes unless you are using multi-value types. You can call against the conversation web-service to extract data and then load it using 'bulk-load' I would not worry too much about creating the attributes unless this becomes essential due to their type or complexity. If you cannot call against the conversation web-service, then again extract as csv and load using Integrator.
I'm working on an iOS app that creates "location sets" where each row contains a location name and a GeoPoint, and each set has its own name. Each of these sets are stored in an object inside our program (all belonging to the same class). Now we want to give users the capability to create sets and upload them to a database, allowing other users to access and download them to their device.
I've been looking in to back-end solutions for work like this, but pretty much everything I've found so far focuses on relational databases and adding and deleting rows and using SQL-like language to retrieve them. Is there a way to store these objects just as objects (and not unpack the info inside to tables), and then retrieve them? It feels like that would be a much simpler way of going about this.
I'm an absolute beginner when it comes to databases, so forgive me if there's info missing here that you would need to help me out. I'll make sure to keep checking back in case someone asks for more info.
Thanks!
Coredata might be useful for you as its based upon the entity. So you can play multiple things around it by using queries (predicates).
But if you just want to save and retrieve back, then as a simplest solution I would suggest to create array/dictionary with entity data, save that into NSUserDefaults so you can retrieve back same while re-launching the app.
Webservices for iOS development:
raywenderlich
icodeblog
WSDL Webservices
Response data parsing, it would be either JSON or XML:
JSON Parsing
XML Parsing
Hope these links would be helpful for you.
I ended up using Parse's mobile back-end service. That was the type of service I was looking for. I've found other similar services since then, like Applilcasa and StackMob, but we're pretty happy with Parse so far.
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?