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.
Related
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.
I have a database in sqlite and I want to use Django to present it and make queries on it.
I know how to create a new database by creating new classes in models.py, but what is the best way to use Django to access an existing database?
This seems to be a question in two parts: firstly, how can one write django model classes to represent an existing database, and secondly how that interacts with syncdb.
The answer to the first of these is that django models are not expressive enough to describe every possible SQL database schema, and instead use a subset that works well with the ORM's usage pattern. Tnerefore you may need to accept some adjustments to your schema in order to describe it with django models. In particular:
Django does not support composite primary keys. That is, you can't have a primary key that spans multiple columns.
Django expects tables to be named appname_modelname, because this convention allows the tables from many apps to easily co-exist in the same database.
If your schema happens to match the subset that django models support or you are willing to make changes to adapt it to be so then your task is simply to write models that match with the schema. The inspectdb tool may provide a useful starting point.
You can test if you've been successful in describing your database by temporarily reconfiguring your project to use a different empty database and running manage.py syncdb, and then comparing the schema that Django created with the schema that already existed. If they are the same (or at least close enough) then you got it right.
If your existing database is not a good match for Django ORM's assumptions then a more flexible alternative is SQLAlchemy. It doesn't natively integrate into django's application system but it does provide a more complete database interface that can work with almost any database; some databases will be easy to map, and some others will require some more manual mapping work, but almost all cases should be possible with some creativity.
As for the interaction with syncdb: the default behavior for this command is to skip over any models that already seem to have tables in the database. Therefore if you've defined models that do indeed match with your existing database tables it should leave them alone. It will, however, create the additional tables required for other apps in your project, including Django's own tables.
Modern Django has support for multiple databases, which could provide you with a further approach: configure your existing database as a second database source in your project and use a database router to ensure that the appropriate models are loaded from that second database, and further to ensure that django won't attempt to run syncdb on this database. This provides true separation at the expense of some additional complexity, but it still requires that your schema be compatible with the ORM's assumptions. It also has some limitations, largely pertaining to relationships between objects that are persisted in different databases.
If you'd like to be able to make versioned changes to the database Django uses, starting with the schema you've inherited from the existing database, then South provides a more flexible and more complete alternative to the builtin syncdb mechanism that supports running arbitrary SQL data definition language statements to make changes to your database schema.
It sounds like you need something like South which will allow you to version and and revert changes to your models.
You just need ./manage.py inspectdb.
I have to create a django project which has two dictinct parts. The producer provides some UI to the user and eventually writes to some models. The consumer uses this data and does some processing and shows some pretty graphs etc.
Technically, these are completely isolated apps used by completely distinct user set. I would love to make them separate django projects altogether but unfortunately they share the db structure. The database is effectively a pipe that connects the two.
How should I structure the project? From what I read, I should ideally have isolated models per app. Unfortunately that is not possible.
Any recommendations?
If you define a "app" and use it inside of your "Django Project" I assume you use INSTALLED_APP's in settings.py to make it known within your environment.
If you look it from this point - its the same as if you use "django-social-auth" in two different projects/services and you share the same DB. I can't judge if its common or uncommon to use the same DB, its a design decision you have to make and you need to be happy with.
If you just like to have users and webusers seperated in your admin, please have a look at
separating-staff-and-user-accounts
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'm new to the nosql world, and from forums and articles that i've read: most of users try to "mix" nosql tools, for example, they use Cassandra and MongoDB together to make a "powerful system", because am beginning with MongoDB, i've downloaded the DjanMon project (am a django fan ^_^ ), of course i've downloaded the special version of django that accepts the NoSql use: Django NonRel, and i've noticed that the Setting file dont "oblige" you to use one specific NoSql solution like in Django with RDBMS where you must specify MySql or PostegreSql or other solution, so, is it possible to mix lot of (or two of course) NoSql solution using Django (for example MongoDB+Cassandra)?
There's nothing to stop you using multiple storage solutions, whether SQL or NoSQL - but the NoSQL solutions all have different architectures, data models and APIs (For example, MongoDB is a document-oriented database, whereas Cassandra is Column-oriented), so you can't usually swap one for another without some effort.
Can you clarify what you are actually trying to achieve? I.e. why are you interested in mixing these two specific solutions?