I'm involve in a new proyect, let explain it briefly.
We have an application server, this server can be interfaces with other systems using udp (this is a design policy, I can change it).
Now we need a web app to collect the information sended by the application servers to show some reports and send back some configuration when we need.
We are very interested in Django with Twisted (or Hendrix), we are very new in python world, I surf in Internet for days and so far I undersand some concepts but I mess about how to start with a proof of concept, so I'm here.
I need an example or guide about how to start, our idea is simple for this proof of concept.
An Application server send some data over udp.
A twisted/django app receive that info and save it in a database table.
A django web page read the database table and show a report. I don't know if the web page need to run on twisted or not.
Please, I read a lot of post for days and I'm lost about how to start.
Thank you a lot in advance.
Best Regards.
Learn each part of your stack one-by-one. Start by following a Django tutorial, then once you're comfortable with Django run the app using Hendrix instead of Django's manage.py, finally add your UDP tasks via Twisted from Hendrix. Lucky for you all the projects you've mentioned have good communities and documentation. You don't have to get everything working perfectly, just get some working pieces.
Write some code, then when you have some running code and you get stuck somewhere, hop back onto Stackoverflow and ask your specific questions.
Update
As it so happens, there's a video which shows how to integrate Django + Hendrix. Give it a shot and tell us how it goes.
I am currently writing a client-server app for the iOS platform. The client is written in Obj-C, and the server uses C++ on OSX11.9. Since I intend to run the server software on an Ubuntu dedicated server, I am trying my best to keep the serverside code portable.
To store data about users and user-game-relations I intend to use an SQL database (most likely MySQL or possibly PostgreSQL since I'm familiar with those). I know that it is possible to read from/write to the database through a filedescriptor just like I do in my TCP module, but I wish to utilize a higher-level SQL communications API to make the programming process quicker.
Can anyone recommend me a good open source/free SQL API for *NIX C++? Any help would be appreciated. Thanks in advance!
You have several options here:
Use native database SDK. They are usually distributed along with the database installation or as separate downloads/packets. The upside is you can get maximum speed out of it. Downside is that you'll be limited by your initial choice - no switching afterwards without rewriting part of application.
Use a C++ ORM (example: ODB). This gives you DB independence along with some tasty features, at the cost of slightly reduced speed.
unixODBC supports both MySQL and PostgreSQL. Take a look at it.
I am writing a C++ application that needs to execute SQL queries in a SQL Server DB and I want to do it using SQL Server Native Client.
The MSDN documentation has no a full reference on it and has a few examples so I am looking for some site having more information on how to connect, execute queries and retrieve results using this API.
Do you guys know where can I more info on it?
Thanks in advance,
Ernesto
In addition to ODBC as Brian mentions, you can also use OLE DB and/or ADO (which actually makes OLE DB "easy" to use). The three options are briefly introduced in this blog entry.
Of the ODBC, OLE DB and ADO options, I think the simplest route would be to use ADO. Using ODBC or OLE DB directly is, in my opinion, a somewhat painful process. It can certainly result in very fast code, but you pay for it in development time. This page has some simple examples.
Edit Since this post was made (both question and answers), OLE DB has been deprecated by Microsoft. So going forward, it probably makes sense to use a solution that does not go through OLE DB. This blog post talks about it some.
I think you are looking for the ODBC API.
You can find many tutorials on Google by typing:
ODBC API reference.
Before you start flaming, I'm going to tell you that I am trying to convince myself that this is a bad idea.
Basically, I'm trying to create a website with some basic accounting functions. My friend, a consultant who only knows excel, asked if this could be an excel spreadsheet instead of a web interface.
I found myself thinking, why is excel not the better tool in this case? It has all the tools a web2.0 app has (scripting, access to a db, basic formatting), and is made for accounting. You could basically use excel to write a program that fetches data from an SQL database, populates some cells, and use formulas for the rest.
Is there precedent to using excel as one would use the browser to make an ajax-y web2 app?
Why is this a bad idea?
Update: just to clarify I meant this to be more a "rhetorical" discussion. I'm not sure why the rest of the message didn't clarify that...
Well, if you made it in excel, then it wouldn't really be a web application. It would be an Excel application.
Not that that's a bad thing though. If it makes more sense to build the app in Excel, then go for it.
The problems you'll have doing it in Excel will be the same as the problems you run into with any desktop vs. web application. For example, How do you handle deploying new versions of the app? How do you handle updating the app for new (or older) versions of Excel? etc.
ETA:
If you want to avoid the bugginess of Excel VBA and the headaches of managing a desktop application, you might want to look into the Google Spreadsheets API. You can use it to create/update Google docs spreadsheets on the fly, including formulas and lots of other spreadsheet goodness. Using a hybrid of web application and Google Spreadsheets might give you the best of both worlds, depending on what exactly you need to do.
After years of programming in Excel-VBA, the best answer that I can give you for not doing this:
Excel-VBA is buggy! It is probably the most bug-filled app that Microsoft has produced. It's great for some tasks, but forcing it to do a job for which it was never intended will lead to trouble.
I have a few spreadsheets that do similar things, (things Bill never intended), and without exception, they teeter on the brink of failure, and tend to crash with only the slightest provocation.
Sure, you can do it, but the headache is not worth it.
Excel was not meant to be used that way, so it will be painful.
Two better ideas for web-spreadsheet integration:
Take a look at Resolver One, a programmable Excel-compatible spreadsheet with an integrated web server.
Use Google Docs spreadsheets. There is an API to interact programmatically with them.
It's not a bad idea, but it does come with some limitations. If deployment isn't an issue for you, and you don't need "universal" access to the application, your solution will likely save you some time. A web application would certainly be a more elegant approach, particularly if you want to make the software available publicly.
The web is inherently based on HTML and added to with Databases, CSS and server-side languages and javascript (possibly others). As with most things, you should use the right tool for the job. If you want a website then you should use the tools for creating a website.
Excel is not meant to make websites, forcing it to do so will likely lead to more frustration than happiness.
Well, you're going to run it on the server side, you'd probably run into licencing and performance issues.
If you're delivering .xls to the client, then you'd need for all your clients to have Excel or something compatible. But you also lose control over your "site" - what's the point of visiting if you have everything you need locally?
So, the SQL statements would be on the client? That's rarely a good idea.
It's a bad idea for the same reason that writing a graphics editor with MS Access is bad, or coding a MMORPG using Powerpoint is bad :)
I would also say that once you stop using a browser as the client it ceases to be a "web application" - you are really just talking about an Excel sheet which fetches its data via HTTP.
+1 to everyone who said "an excel app is not a web app."
BUT... If you want to use the spreadsheet metaphor for server-side calculations for a web app, or if you want to access the library of financial functions that come with Excel from server-side code, you can use Excel Services. It's exposed via SOAP, interoperable, callable from any SOAP-capable platform.
It's server-capable. It does not actually load Excel on the server, but a non-GUI runtime of the functions.
I think that using Excel as Browser is bad idea, however i think better idea is to use Excel Control in Desktop App.
This way you can control the sql and connections. you can save data as often as you like. you could also implement some update mechanism. App would be more secure and harder to hack.
I think Excel freezes when you try to connect to some outside resource and this way you would control everything.
Did you start by getting user requirements for this application? It doesn't sound like they wanted a website to begin with. Sounds like they wanted an excel spreadsheet with macros.
I'm wondering what kind of persistence solutions are there for C++ with a SQL database? In addition to doing things with custom SQL (and encapsulating the data access to DAOs or something similar), are there some other (more general) solutions?
Like some general libraries or frameworks (something like Hibernate & co for Java and .NET) or something else? (Something that I haven't even thought of can also be welcome to be suggested)
EDIT: Yep, I was searching more for an ORM solution or something similar to handle sql queries and the relationships between tables and objects than for the db engine itself. Thanks for all the answers anyway!
SQLite is great: it's fast, stable, proven, and easy to use and integrate.
There is also Metakit although the learning curve is a bit steep. But I've used it with success in a professional project.
It sounds like you are looking for some ORM so that you don't have to bother with hand written SQL code.
There is a post here that goes over ORM solutions for C++.
You also did not mention the type of application you are writing, if it is a desktop application, mobile application, server application.
Mobile: You are best off using SQLite as your database engine because it can be embedded and has a small footprint.
Desktop App: You should still consider using SQLite here, but you also have the option with most desktop applications to have an always on connection to the internet in which case you may want to provide a network server for this task. I suggest using Apache + MySQL + PHP and using a lightweight ORM such as Outlet ORM, and then using standard HTTP post calls to access your resources.
Server App: You have many more options here but I still suggest using Apache + MySQL + PHP + ORM because I find it is much easier to maintain this layer in a script language than in C++.
MySQL Connector/C++ is a C++ implementation of JDBC 4.0
The reference customers who use MySQL Connector/C++ are:
- OpenOffice - MySQL Workbench
Learn more: http://forums.mysql.com/read.php?167,221298
SQLite + Hiberlite is a nice and promising project. though I hope to see it more actively developed. see http : // code.google.com/p/hiberlite/
I use MYSQL or SQLite.
MYSQL: Provides a server based DB that your application must dynamically connect to.
SQLite:Provides an in memory or file base DB.
Using the in memory DB is useful for quick development as setting up and configuring a DB server just for a single project is a big task. But once you have a DB server up and running it's just as easy to sue that.
In memory DB is useful for holding small DB such as configuration etc.
While for larger data sets a DB server is probably more practical.
Download from here: http://dev.mysql.com/
Download from here: http://www.sqlite.org/