I built an app in Django, and have a script I wrote in Java that I'd like to use on the data from the Postgres database.
I understand I can simply run a raw SQL query with the data in Java, but would it be more efficient to create ORM models with Java to access and process the data?
More generally, if I mainly use a database with one framework, but need to access the data with another language or outside of the framework, should I build models with an ORM or use raw SQL?
That is up to you, there is no one-size-fits-all solution for this. Because you cannot directly work with the whole Django framework you will have to create and maintain the database interface in your other language.
but need to access the data with another language or outside of the framework
Depending on the proportion of data you need to access, you may consider creating and communicating with an API instead, for instance using Django REST Framework. If your Django app is, and will remain the core of what works with the data in this database, this is probably the most sensible way to deal with interfacing to that data from other languages and environments.
Related
Recently we are working with Rails Now want to attach module working with Django. Can We use same data Base for both project. Secondly postgresql db is used here.If any framework or gem present that can handle this.
The cool thing about a general-purpose relational database (or actually one of the many cool things) is that you can use it with all kinds of programming environments – all you need to do is use the proper driver. So that should be no problem technically.
If the two programs work on the same data, let them share the database. If they operate on different data, create a new database.
I am not that experienced with django yet, but we are creating a project soon and we were wondering which database to use for our backend (Mongodb or PostgreSQL).
I've read a lot of post saying the differences between each, but I still can't take the decision of which to go for. Taking in consideration I never worked with Mongodb before.
So what shall I go for ??
Thanks a lot in advance
MongoDB is non-relational, and as such you cannot do things like joins, etc.
For this reason, many of the django.contrib apps, and other 3rd-part apps are likely to not work with mongodb.
But mongodb might be very useful if you need to store schemaless complex objects that won't go straight into postgresql (of course you could json-serialize and put in a text field, but using mongodb instead is just way better, allows you doing searches, ..).
So, the best suggestion is to use two databases:
PostgreSQL for the standard applications, such as django core, authentication, ...
MongoDB only for your application, when you have to store non-relational, complex objects
You also might want to use the raw_* methods that skip lots of (mostly unnecessary) validation by the django orm.
Just remember that databases, especially sql vs no-sql, are not drop-in replacements of each other, but instead they have their own features, pros and cons, so you have to find out which one suits best your needs in each case, not just pick one and use it for everything.
UPDATE
I forgot to say: remember that you have to use the django-nonrel fork in order to make django support non-relational databases. It is currently a fork of django 1.3, but a 1.4-based version is work-in-progress.
I've prototyped a web application with Django. Some parts of the model structure are currently simple Django models which currently simulate the data structure of an legacy data store that I need to integrate. These so called master data will be read only for the app. The master data is (I think) exposed via a webservice to me, but I guess this is somewhat irrelevant.
Essentially I need to create some kind of proxy object, that I swap in for the current model. I would like to leave as much as possible of the remaining application code untouched. I'm aware that this will probably limit the amount of Django magic I can use for these "faked" models (no auto generated forms, no admin interface) but I'm okay with that.
Is there anything that I could use?
I have just started playing around with django. I can foresee one app generating data that another could use (bad example: a geomatics app crunching complex data to generate simple location data to pass to another app that uses the data to decide some sort of business logic). Having never done any web programming with frameworks, my first thought was ....globals... But thats obviously not a "good thing"!
Return a key to the client (either via a cookie or in the session) that can be used to retrieve the information from a datastore when needed.
I am relatively new to Django and this is a more general 'concept' question.
For a client I need to construct an expansive database holding data returned from a series of questionnaires as well as some basic biological data. The idea is to move away from the traditional tools (i.e. Microsoft Access) and manage the data in a mysql database using a basic CRUD interface. Initially the project doesn't need to live on the web, but the next phase will to be to have a centralized db with login and admin page.
I have started building the db with Django models which is great, and I want to use the Django admin for the management of the data.
My question is: Is this a good use of Django? Is there anything I should consider before relying on django for the whole process? And is it advisable to us the Django runserver for db admin on a client's local machine (before we get to the web phase).
Any advice would be much appreciated.
Actually, your description sounds exactly like the sort of thing for which Django is an ideal solution. It sounds more complex and customized than a CMS, and if it's as straightforward as your description then the ORM is definitely a good tool for this. Then again, this sounds exactly like an appserver-ready problem, so Rails, Express for Node.js, or even ChicagoBoss (if you're brave) would be good platforms for this kind of application.
And sure, Django is solid enough you can run it with the test server for local clients before you go whole-hog and run the thing on the web. For that, though, I recommend Apache/mod_wsgi, and if you're going to be fault tolerant there are diamond architectures (one front end proxy with monitoring failover, two or more appserver machines, one database with hot spare) and more complex (see: sharding) architectural layouts you can approach later.
If you're going to run it in a client's local setting, and you're not running Windows, I recommend looking into the screen program. It will allow you to detach the running job into the background while making diagnostics accessible in an ongoing fashion.