I have just started taking a look at rocksdb and was able to build a small springboot based app to perform basic CRUD operations on it. However, I was wondering if there is a ui tool that can be used to query or browse the data in rocksdb.
I am not sure if this is a valid question, but something like pgadmin for postgres or a client utility that can be used to browse through the data in this db?
Thanks, HK.
No, there isn't.
The reason for that is that there is no way a GUI client can know how to deserialize your data format.
I might save my values as pure strings - you might have it as json bytes - someone else might use protobuf - how would the gui client know how to deserialize it and show it in the UI?
Or would it just show the bytes? Which is unlikely to be useful
Related
I have developed a Client/Server application for IM with Qt. So far messages are sent and displayed at the client side, but when the program is closed the messages are no longer available since a proper storage is missing.
I would like to keep the messages on the client devices and avoid to store everything on the server. I don't want to use a DB either since it needs to be installed and I would like to keep everything quite easy.
Therefore I was thinking of simply storing everything in an encrypted file, but I couldn't think of a proper format to do that.
Has anyone experience with that or any suggestions how to save the messages from different clients?
You do have a concern with data integrity in face of unplanned termination of your software, due to bugs in your code, transient hardware errors, power outages, etc. That's the problem that everyone using "plain files" usually ignores, as it's a hard problem to solve and requires extensive testing and know-how.
That's why you should use an embedded database. It will solve that, and many other problems as well. SQLite is a de-facto standard for applications such as yours. You can add any encryption you wish, as SQLite provides hooks that let you implement writing and reading of the pages. You'd do the encryption there.
One little-appreciated aspect of SQLite specifically is the amount of testing it gets during development. The test harness, most of it non-public, is probably worth way more than the published SQLite code (>1M USD). SQLite is used in aerospace applications, e.g. IIRC in code classified as DAL-B under DO-178B.
I am in the beginning stages of writing an angularjs client that talks to a RESTful ASP.net Web Api server and am trying to integrate Breeze. I have full control over both client and server code, but the one non-negotiable is that I have to connect to a DBISAM database that I'm sharing with a legacy Windows desktop app; so I can not take advantage of the Entity Framework that most Breeze Server examples use. I've successfully retrieved data by setting up a controller similar to the one in the NoDB example and am now trying to figure out the best way to get real data from my database. Also, I am able to get data from the DB using the ODBC connection, but I'm just not sure where that will fit in with the Breeze way of doing things.
Given all of that, here are my specific questions:
are there any Breeze Server examples showing how to retrieve/save data using a database connected via ODBC that I have somehow overlooked?
will I need to create an adapter to make this work? And if so, is the mongodb adapter the closest thing to use as an example of what that code should look like?
Without Entity Framework, is it still better to return the metadata from the server, or should I create it on the client instead?
I understood the documentation to say that it is easier to have the server be Breeze "aware", but is that still true when needing to use ODBC? Perhaps I should just use Breeze on the client side instead, similar to the Edmunds example?
thanks for any help with figuring out the best way to proceed!
I am planning to create sqlite table on my android app. The data comes from the the server via webservice.
I would like to know what is the best way to do this.
Should I transfer the data from the webservice in a sqlite db file and merge it or should i get all the data as a soap request and parse it in to table or should I use rest call.
The general size of the data is 2MB with 100 columns.
Please advise the best case where I can quickly get this data, with less load on the device.
My Workflow is:
Download a set of 20000 Addresses and save them to device sqlite database. This operation is only once, when you run the app for the first time or when you want to refresh the whole app data.
Update this record when ever there is a change in the server.
Now I can get this data either in JSON, XML or as pure SqLite File from the server . I want to know what is the fastest way to store this data in to Android Database.
I tried all the above methods and I found getting the database file from server and copying that data to the database is faster than getting the data in XML or JSON and parsing it. Please advise if I am right or wrong.
If you are planning to use sync adapters then you will need to implement a content provider (or atleast a stub) and an authenticator. Here is a good example that you can follow.
Also, you have not explained more about what is the use-case of such a web-service to decide what web-service architecture to suggest. But REST is a good style to write your services and using JSON over XML is advisable due to data format efficiency (or better yet give protocol-buffer a shot)
And yes, sync adapters are better to use as they already provide a great set of features that you will want to implement otherwise when written as a background service (e.g., periodic sync, auto sync, exponential backoff etc.)
To have less load on the device you can implement a sync-adapter backed by a content provider. You serialize/deserialize data when you upload/download data from server. When you need to persist data from the server you can use the bulkInsert() method in content-provider and persist all your data in a transaction
I'm working on the following scenario:
I have a console up that populates a SQL Server database with some data. I have one more web app that reads the same database and displays the data on a front-end. Both of the applications use Entity Framework to communicate with the database (they have the same connection string).
I wonder how can the web app be notified for any changes that have occurred to the database. Bear in mind that the two applications are not referenced, whatsoever.
Is there event provided by EF that fires when some has changes. In essence, I would like to know when a change has happened, as well as, the nature of that change
I had a similar requirement and I solved it using the EF function:
[context].Database.CompatibleWithModel(throwIfNoMetadata: true)
It will return if your model matches the underlying database structure using the metadata table.
Note that I was using a Code First approach.
The msdn definition is below:
http://msdn.microsoft.com/en-us/library/system.data.entity.database.compatiblewithmodel(v=vs.103).aspx
Edit:
Just found an amazing article with a demonstration:
http://blog.oneunicorn.com/2011/04/08/code-first-what-is-that-edmmetadata-table/
This is not something that is related to EF at all. EF is just a library that makes SQL calls and maps them to objects. It has no inside knowledge of the database. As such, when data changes in one application, another application doesn't know unless they query to see if that data changes (and you're not going to be constantly running queries to know that, it's too impractical).
There are, potentially some ways to do this, such as adding triggers to the database, which then call extended stored procs to send messages to the app, but this is a lot of work to go through, and it can possibly compromise the robustness of the database.
There used to be something called Notification Services, but that was deprecated. There's now something called SqlDependency objects, which may help you in some cases.. but it all depends on what you're trying to do exactly.
In any event, it's usually easier to find a different way to do what you want. This is complex topic, and really requires a lot of sql server knowledge.
I would like to know which is faster. Let me give you the scenario. I'm on a LAN, have a report to build using data from a SQL Server database (if we need the version let's say 2005) and have these ways of getting the report done:
Have a web service at the server, where the data is taken from the server and serialized into XML. The client uses this XML as a source for a report that is built in the client machine. The cliente would be a windows form app.
From the client side, connect to the database using ADO.Net, get a DataTable and uses as a source for the report built in the client.
The same as (2) but using a DataReader.
Also, is there a better way to do this?
The serialization to XML is going to cost both in terms of the time it takes to do it, the overhead of the XML structure, and the time to deserialize. It will, however, provide a format that is consumable by more technologies. If you are using .NET end-to-end, and that isn't likely to change, I would not use XML, but use the framework-provided data access methods. Personally, I would probably use LINQ over DataTables or a DataReader but that more for ease of use and readability on the client-side than any performance advantage.
The best practice is to not use .NET-specific types in the interface of a web service. Even if you are certain today that your service will never be called by anything other than a .NET program, things change, and tomorrow you may be told that the service will be called by a Perl program.
Perl programs don't understand DataSet. Nor do Java programs, nor anything other than .NET.
The best practice is to create a Data Transfer Object containing just the data you need to transfer, in simple properties with primitive types, or collections or arrays of primitive types, or collections or arrays of Data Transfer Objects, etc. These will be understandable by any client.