I have scyllaDB installed in cloud. I want to run queries and check the data. Is there any way to access it by any desktop UI client or does by default it provides any web UI to access it
Thanks
The typical interface with ScyllaDB is cqlsh which is command line. Documentation is at https://docs.scylladb.com/getting-started/cqlsh/
There are a few GUIs that claim to be front-ends for Cassandra. These should work for Scylla, but I've never used them.
Related
I am trying to build a middleware application ( you know...retrive data from a webservice and store to db in cPAnel and send the data to the webservice hosted from here)
Is it possible to run an application in cPanel?
If it is possible what is the prefferedlanguage for this purpose and
why?
If I am trying to run an application which has to update this fetch
hourly automatically form code.is it possible.means i want this
application to be in running state for an indefinite time.Is it
possible?
My thoughts are:
1. cPanel is not a jumping off point for applications. It is simply a shared hosting management console. It gives you the ability to do some management. You can fire off applications by making a cronjob.
Generally you have two choices, you can use shell scripting or PHP invoked from a shell.
Now this narrows it down further. PHP is configured to have a maximum execution time to stop people hogging the processors.
If you are going to write some proper middleware, I'd suggest that you either get yourself an Amazon, Jelastic or some other cloud hosting provider. You will get the ability to deploy a real application, on a full operating system - rather than "hacking" a solution.
cPanel based installs are really for those people who just want to put a website, whack up a blog, or do some low bandwidth hosting. Running something constantly is going to have you violate the terms of service on these accounts very quickly.
I would like to use MongoDB directly at client side of an Mac OSX app, i.e. I want to store my models in a mongoDB. Is this possible? Most of the documents I saw explained how to access mongoDB that is present in a server.
There are undoubtedly a lot of other options for databases, even Mongo-like databases, but if you want to use Mongo on the client, by far the simplest way is to run Mongo as a separate process on your client machine. Using Homebrew or the 10gen Mac installer you can have it running in a few minutes. By default the server doesn't require authentication, so there's almost nothing to configure.
I wrote ObjCMongoDB. Using that it's simple to interact with the local instance.
A local instance plus a driver is the same way you'd build an application if you were required to use say PostgreSQL or MySQL – though again, there are other options for databases. It's perhaps a little easier with Mongo since collections just pop into existence when you start using them.
There's not an easy way to embed Mongo into a Cocoa app.
If you want something like MongoDB running on the client side, I'ld recommend you to use ejdb instead. It's specifically built for that purpose.
It aims to be a fast MongoDB-like library which can be embedded into
C/C++/NodeJS/Python/Lua/Java/Ruby applications under terms of LGPL
license.
I'm trying to build a small webapp that will handle our development environments located on an openstack infrastructure (version 2012.2.2-dev, bundled in ubuntu 12.04) and I need to create some volumes using the API (i decided to use openstack rest api). I'm able to start machines and do some other operations (everything is built based on this: http://api.openstack.org/api-ref.html). If I send the request to create a volume as explained on the api reference, i get a 404. I tried different api versions (v1), but still no success.
Thank you in advance.
What language are you coding in? You could just use an SDK for this and skip trying to talk to the API directly. See
https://wiki.openstack.org/wiki/SDKs
In newer releases of OpenStack it is preferable to make use of the Cinder API rather than Nova API.
In folsom, Cinder uses IDENTICAL API refs to Nova volume related API sets. This is because this was the first release to separate out volume management to cinder as a stand alone project. While volume API references remain in folsom it is not the default and it is not the preferred method for accessing volumes REST queries.
Check out.
http://docs.openstack.org/developer/cinder/
We are currently planning to develop a suite of Windows Store Apps. They are independent and fully work alone, but they are related and act in concert. If a user has several of them, they should share some of their settings (and data), so that the user does not have to manually change these settings in every single one of them.
Is such a scenario even intented?
And how to implement it?
Registry: Does not work. Apps cannot access the registry.
ApplicationData (LocalFolder, LocalSettings etc.): Does not work. Apps cannot access the data of other apps.
Cloud services: Kind of works, but only when the machine is online. Our apps should work offline, too. And we would need to create/rent such a cloud service, which would cause additional costs.
KnownFolder.DocumentsLibrary: This –currently– looks like the only solution to me. The apps are already saving and sharing data there, so let's just save our settings there, too. But the name of the shared folder is one of the settings! And Windows Store Apps cannot create hidden files, so the user can see the settings file. This makes this solution a bit... "rough".
Any other ideas or additional information I have missed?
If you want them to sync with each other instantly, even when the device is offline, then that's your only option. Windows 8 Apps are not intended to share settings.
So much want of sharing.
Roaming API will only share with the SAME app, the SAME user, ANY W8 device.
SkyDrive will only share across ANY app, the SAME user, ANY device.
Using Azure (or any web service) will share across ANY app, ANY user, ANY device.
Don't do this
Don't use the register, the API is not supported
Don't use the file system, the boundaries cause your app to be brittle
Don't use ApplicationData.AnyFolder, this is restricted to a single app GUID
You had might as well get "instant" out of your language, man. That just doesn't happen. But you can have fast (let's call it near instant); you can use Sockets or SignalR to connect your client to some service out there with nearly instant responses. A less sophisticated approach would be to poll from your client, too. It has served developers for decades.
Many applications use the following model:
Browsers or other clients interact with application servers.
Application servers (web servers or RPC servers) interact with data store servers (SQL servers or non-SQL storage).
For internet applications, they need application servers because they must keep simple feature on data servers for performance. But I can't see why they need application servers on intranet.
For example, can we develop an Adobe AIR application, which directly connect to a PostgreSQL server? I guess we can deploy a center PostgreSQL server which has many stored procedures and set strict permission, and let the Adobe AIR application fetch (and modify) data only by invoking the stored procedure.
Why don't the most of applications choose a simplier solution?
In general, there is no reason why you couldn't get an independent application to talk to a PostgreSQL server directly. Some applications do this and it works fine.
I'm not familiar enough with Adobe AIR to say whether it's possible in this context. In principle, if you can get a PostgreSQL driver, or if you can write your own using TCP sockets (the PostgreSQL network protocol is documented in details in the official documentation), you could certainly connect directly.
This being said, having a form of application server between the end-client and the database server isn't purely for performance.
Web-based development allows the SQL queries to be controlled by the server. Instead of exposing complete SQL access, you expose the features that the client can use. If you need to tweak the queries later (bug, change of data structure, ...), you can do this rather centrally on your application server, without having the need to deploy a new version of the client to each user.
Of course, you can do some abstraction like this user server programming directly, but this isn't suitable for all applications. This may depend on what other features your application needs, for example if it needs to make use of a library programmed in another language. You can use some procedural languages bindings, but it's not always suitable: pl/Python is an "untrusted" language (which may cause security problems) and pl/Java needs a external add-on, for example.
In addition, not all applications are ultimately reserved for intranet usage nowadays. It often makes sense not to restrict yourself to intranet usage when you start designing an application.
I initially started with a direct access design and quickly found it useful to move to an application server where I talked to the DB via web services. Reasons included:
Handling DB restart, local connection loss, client IP address change, etc is much easier when you're talking to the DB over a stateless protocol like HTTP. This is more of an issue for remote workers.
Transactions are clearly demarcated and isolated in server-side transactional methods (I used EJB3 and container managed transactions)
It's much easier to add new clients like a phone app as they can share more of the code and business logic. Stored procedures in the database are very useful, but can be limited and occasionally frustrating.
Some tools/languages don't have built-in tools for talking to PostgreSQL directly, but can easily talk to a RESTful web service with XML or JSON request/response format.
DB admin is easier if you're dealing only with a single application server connection pool
The main downside is of course the extra layer means extra work and extra maintenance.
You can, but...
Browser languages/libraries tend to have poor database support
What happens when someone wants to use this application remotely?
If you're not talking about browser-based applications, then that is exactly what many do. There are plenty of traditional installed client applications talking to a backend database either directly or via a wrapper (odbc/jdbc).