Google app engine offer a data store (some kind of DB wrapper) to hold your data.
It does not supply an editor to this data store - only a viewer.
When developing a web application with other DB - MSSQL, MySql etc. - I change the DB structure in the development process many times.
In AE data store you should edit it's structure and data by using code - Java in my case.
Do you - AE developers - have any best practice to manage this DB updates and save them in some smart way for deployment?
I don't know about "best practice", but I have a Servlet that I use during development which can upload and download all entity data as JSON.
I can then use a regular text editor to make changes or I use a hacked version of JSONpad to edit data live in the system.
Since, I use JSON through out my application this works best for me. One could also do the sample thing with XML and use any one of the many XML editors.
Also, I do use the low-level API for all my applications, so my data models tends to be fairly simple.
There are plenty of JSON/XML editors that could be adapter for your purposes, with a little bit of work.
Related
I am working on a webapp for a client that has a cPanel virtual server, and it appears that I can only use MySQL, but I want to store the data using a json-like structure, so that I can more easily use Angular.js on the frontend.
I've looked into installing a NoSQL database, and I can't find anything viable (if you know of a way to do that, that would be my best solution), so I'm thinking of storing the data as json strings in a series of text files on the server that I would write to with php.
I'd like to hear some opinions, and if there are any better solutions of which I'm not thinking of.
Go look at firebase and thank me afterwards.
In short, firebase is a cloud real-time JSON data storage. Everything for the backend is done for you and all you need to do is the front-end. Their servers are CDNs which means it will be great if you're looking to serve the entire world. All you need to do is configure your data-structure and use it!
It also provides sockets, which is great for real-time data (used for games, chat and etc).
There is a free option. The only downside is that it is a little expensive if you want to scale it, nevertheless if your app really gets to that stage - I'm sure you'll have money to hire some people to develop a similar backend for yourself.
I have a small django website where people have signed up and uploaded pictures and stuff.
I now want to rebuild the website API. This will change the database schema and I want to migrate all the user information from old database to new database.
Whats the best practice of doing this? Links to tutorials will be helpful.
The database backend is postgres-postgis.
TIA
There are different approaches to data migration. In my previous employer we rewrote much of the code from scratch and before deploying the new application we had to migrate old data. Two methods are:
Migrate data from the first schema directly from the DB: This is
very useful especially if the data you have in legacy DB is huge. If
you let the DB copy from one table/database to another it will be extremely
fast. You need to have SQL knowledge for this though (google 'insert into from another database').
Write a script or django command to load the data into django models and go from there. This will not be as fast as DB option but it may be easier to code and depending on your scale of changes, your only option. If you are going to do some computation beforehand then a high level language such as python will be helpful.
I was actually reading up on CMS systems like Drupal, and noticed that they're similar to RDBMSes. I was wondering what the differences might be between them. When would we use an RDBMS and when would we use a CMS? Kinda confused and appreciate any input on this. Thanks!
You are asking what is the difference between a car and a Diesel engine.
CMS (Content management system) is a full-blown system allowing end-users to view and modify content (articles, media, etc.) in an easy way. See: List of content management systems.
RDBMS (Relational database management system) is a back-end software used to store low-level data. Typically CMSes use RDBMSes (like MySQL), but this is not a requirement. Nowadays end-users seldom use RDBMS directly.
After researching this topic (and being a Senior Oracle DBA and Java Developer) and reaching a good understanding of both, I can answer this.
Think of a CMS like Amazon, they host digital content such as books, movies and a myriad of other merchandise. Amazon has a fairly open ended query capability that helps you find products quickly and accurately (most times anyway!).
Now imagine this, Amazon goes in and organizes content a little different for logic/efficiency sakes, so what happens to the applications that use it...typically nothing!
You have to create a schema in an RDBMS and write code to interact with that schema. A CMS has facilities to store, organize and retrieve content (although some software would have to be developed that uses/interfaces with the "system"). Arguably, one could create database tables that have blob/clob types and make something CMS like.
One fine difference is that a CMS can support MIME types such as PDF and .DOCX files and understand how to search those for content as well (unlike a BLOB, it's just a BLOB right?).
I wouldn't limit a CMS as saying it is a "document repository" for web-based applications, because it is much more than that; a CMS can store structured, semi-structured and completely unstructured data (executables/.bin files/imagery...whatever!)
They're not similar at all. A CMS is a Content management System - it's used for maintaining content in a website. In a CMS you generally think of content as "pages" or "documents"
An RDBMS is a Relational Database Management System. An RDBMS manages data - in the form of text, numbers, etc, in a highly relational format. In an RDBMS, you think of data as "numeric values", strings of "text", "datetimes", or other primitive data formats.
Usually a CMS uses an RDBMS under the hood to store the data, which the CMS displays as page content.
They are really not the same:
RDBMS : Relational Database Management System - for handling data (SQL, MYSQL)
http://en.wikipedia.org/wiki/Relational_database_management_system
CMS: Content Management System - For working with web site content
http://en.wikipedia.org/wiki/Content_management_system
I think you are missing the point here...As far as i know a CMS uses an RDBMS to provided its data. As far as i know a CMS is just an abstraction layer built upon a database. It's much easier for a user to edit content by using the cms, then by directly editing data in a database table.
A CMS, strictly speaking, is a Content Management System, typically used for serving up web pages (SharePoint and other document repositories not withstanding). An RDBMS is a Relational Database Management System. CMSs usually reside within an RDBMS. RDBMSs are also typically used for much more intensive purposes than a CMS, for example, storing customer information or product data.
So one can integrate code e.g. java ... in a CMS to interact with a RDBMS e.g. MySql to endup with a CRUD (Create , Read, Update, Delete) web type application ?
The idea behind this, is to allow any user of the web site to update (specifically allowed) data stored in the RDBMS.
We seem to be getting close to an eCommerce website ...
CMS+RDBMS+code = eCommerce website
Not sure if that exists though ?
I want to migrate part of a Drupal 6 site to a Django application, specifically a Drupal based questions and answers section that I think would work better with OSQA. I've already created another question related to the authentication part of this integration and for the purposes of this question we can assume that all Drupal users will be recreated, at least their usernames, in the Django database. This question is about the data migration from Drupal to Django.
In Drupal I have all questions as nodes of a 'question' content type with some CCK fields and the answers to these questions are standard comments. I need help to find the best way of moving this data to OSQA in Django.
At first I thought I could use South but I'm not sure if it would be the best fit for my needs.
For now I think my best approach would be to write a Django app that connects to the Drupal database, query for all the questions with their corresponding comments and users and then insert directly to Django's database using the correct models and Django methods.
Am I on the right path? Any other suggestions?
Thanks!
At first I thought I could use South but I'm not sure if it would be the best fit for my needs.
No, South is not for this kind of migration. It is for intra-project migrations, and you will want to have it, but it doesn't really do you any good here.
"Migration" is really not a good term for what you need. What you really want to do is export data from Drupal and import it into Django.
I haven't made an in-depth analysis of the possible solutions for this, but were I asked to do the same thing, I would simply define a JSON- or XML-based interchange format for the transfer, then write one set of code to export the data from Drupal to this format, then another to import data from this format into Django. I strongly recommend against using a binary format for this interchange; the ability to load the data into a text editor to verify your data and fix things is really important.
For now I think my best approach would be to write a Django app that connects to the Drupal database, query for all the questions with their corresponding comments and users and then insert directly to Django's database using the correct models and Django methods.
If you want to skip the interchange file and do it in one step, then you don't want to write a new Django app just for the import; that's (IMHO) overkill. What you want to write is a Django management command within the app that you will be importing data into, and you probably want to use Django's support for multiple databases as well as model properties (such as db_table and db_column) for using existing database schemas. This is why I recommend the interchange file method: you wouldn't need to reimplement Drupal tables in Django models.
Mike's answer is the good path to follow. However in real world scenario you can find useful to mix different techniques, for example connect to the original Drupal database for the files referencing a local directory for file content (query for files are simple join from few tables) but processing the most structured data via a custom JSON view (e.g. nodes).
In these case a JSON View created via Views Datasource module can help you to design and select your data via a simple Drupal view. Then you can write a management command to read and parse the data as suggested before. You have to page the view in a way that doesn't request too much to process and you can even do asynchronous requests to speed up the retrieval using gevent.
In this way I parsed more than 15k of contents in less than 10 minutes, not so fast but acceptable for one-time import. If you want to store content for process it later you can save raw data on a custom model on the database or on a on-memory redis data store via python redis integration. If you want some detail I've written a detailed howto for Drupal-Django migration deepening these techniques.
I'm hoping you can help.
I'm looking for a zero config multi-user datbase that my winforms application can easily upload to a webserver folder (together with 1 or 2 classic asp pages) and am looking for some suggestions/recommendations.
The idea is that the database will be used to collect feedback entered by people filling in the asp pages. The pages will write to the database using javascript.
The database will subsequently be downloaded again for processing once the responses are in.
In Summary:
It will mostly run in MS Windows environments.
I have a modest budget for this and do not mind paying for such a database.
No runtime licensing costs.
Should be xcopy - Once uploaded to a website folder it should be operational.
It should not have a dotnet CLR dependency.
It should support a resonable level of concurrent access. Average respondent count would be around 20-30 but one never knows.
Should be a reasonable size so that uploads/downloads to and from the site will be reasonably fast.
Would appreciate your suggestions/comments
Many thanks
Abz
To clarify - this is a desktop commercial application for feedback management in a vertical market. It uses SQL Server as the backing store.
The application currently provides feedback management from email and paper feedback. I now want to add web feedback capability. Getting users to to make their SQL servers accessible to a website is not at option at this time as I am want to make getting up and running as painless as possible.
I intend to release a web based implementation of the software in the near future but for now am looking at the above as a pragmatic way to provide web based feedback collection.
SQLite comes to mind. It meets all of your stated requirements, is open source, and has a liberal license (public domain).
http://sqlite.org/
I would use 'normal' database (say MySql, Postgresql, Firebird, etc.) on server. Instead of copying files to server your winforms application would create custom tables (or even custom databases). After collecting data you could just get it back to your application using plain old SQL.
why reinvent the wheel ? If you want to collect feedback and stuffs from users of your app and if they are connected to internet, it might be a better idea - and in the long term cheaper - to use a service like wufoo. We recently switched from homegrown setup to wufoo and are very pleased. Check it out.
Otherwise you might want to take a look at sqlite orfirebird. Both of them are very robust, and have ADO.NET providers. Firebird scales from a single user to full blown client server system and has no .NET dependency.
If you really don't want a DB/SQL Solution, you could try simple text files and ftp/xcopy files down and parse them into the back-office server as needed. ASP/VBScript or ASP.NET can create the files to store the basic feedback comments. Need to consider security of course!