I always use SQL or NoSQL databases in my project and at my job, but now I am asked to use an object-oriented DB. I don't even know for what reason I should do that. Despite this fact, I google for OODBMS in python and can't see any easy way to use this approach. Now I think, that django ORM (and flask sql alchemy) are the simplest way to construct databases.
So, I have two questions:
What are the main benefits of using OODBMS instead of, e.x., Django ORM?
Is there a simple way to use OODBMS in flask and django?
For question 1: OODBMS offers many benefits and to mention a few:
It provides greater consistency between the database and the programming language.
Doesn’t bother you with object–relational impedance mismatch.
It is a more expressive query language and it supports long
durations/transactions.
It is also suitable for advanced database applications.
For question 2: ZODB is easier and simpler to use, Django is mostly good with ORM only.
Related
I am kind of new to sql and database & currently developing website in django framework.
During my reading of django documentation I have read about raw sql queries which are executed using Manager.raw() like below.
for p in Person.objects.raw('SELECT * FROM myapp_person'):
Manager.raw(raw_query, params=None, translations=None)
How does raw queries differes from normal sql queries & when should I use raw sql queries instead of Django ORM ?
Django (like other similar ORM tools) is a connection between relational databases and object-oriented programming. One of the very important functions that it implements is providing a uniform interface to the database -- regardless of the underlying database.
When you use underlying Django functionality, the code should be supported on any database (there may be specific limits on this). This makes it particularly easy to port to another database. It also helps ensure that the generated queries do what you intend.
When you use raw SQL, the code is likely to be specific to one database (creating a porting problem). The code is also not checked, which can result in hard-to-understand errors.
I have a strong preference for using SQL directly -- but that is because I am not a programmer using an ORM framework. If you are going to use such a framework, it is probably better to use the built-in functionality wherever possible.
This is a borderline opinion question so might get flagged, but it is a good point. Essentially the raw SQL queries are intended to only be used for the edge cases where the Django ORM does not fulfil your needs (and with each new version of Django it support more and more query types so raw becomes less useful).
In general I would suggest using the ORM for the more helpful error messages, maintainability, and plain ease of use, and only use raw as a last-resort
I want to retain the flexibility of switching between MySQL and PostgreSQL without the awkwardness of using an ORM - SQL is a fantastic language and i would like to retain it's power without the additional overhead of an ORM.
So...is there a best practice for abstraction the database layer of a Python application to provide the stated flexibility.
Thanks community!
While SQLAlchemy is a great option. There are others. If you find that SQLAlchemy is not to your liking here are some other ORMs that may work out better for you. Some of them are more lightweight, so it may be more what you're looking for.
http://coobs.eu.org/xrecord/ -- From the description sounds like what you may be looking for. It sounds pretty lightweight and just a database abstraction, but seems to be a little outdated.
http://autumn-orm.org/
http://charlesleifer.com/blog/peewee-a-lightweight-python-orm/ -- includes benchmarks that look pretty good for the basic uses that are done.
http://elixir.ematia.de/trac/wiki -- This is built on top of SQLAlchemy, but has the ActiveRecord style syntax. It may be more to your liking.
https://storm.canonical.com/FrontPage -- An ORM used by Canonical.
Have a look at SQLAlchemy. You can use it to execute literal SQL on several RDBMS, including MySQL and PostgreSQL. It wraps the DB-API adapters with a common interface, so they will behave as similarly as possible.
SQLAlchemy also offers programmatic generation of SQL, with or without the included ORM, which you may find very useful.
Is it even possible to create an abstraction layer that can accommodate relational and non-relational databases? The purpose of this layer is to minimize repetition and allows a web application to use any kind of database by just changing/modifying the code in one place (ie, the abstraction layer). The part that sits on top of the abstraction layer must not need to worry whether the underlying database is relational (SQL) or non-relational (NoSQL) or whatever new kind of database that may come out later in the future.
There's a Summer of Code project going on right now to add non-relational support to Django's ORM. It seems to be going well and chances are good that it will be merged into core in time for Django 1.3.
You could use stock Django and Django-nonrel ( http://www.allbuttonspressed.com/projects/django-nonrel ) together to get a quite unified experience. Some limits apply, read docs carefully though, remembering Spolsky's "All abstractions are leaky".
Yo may also check web2py, they support relational databases and GAE on the core.
Regarding App Engine, all existing attempts limit you in some way (web2py doesn't support transactions or namespaces and probably many other stuff, for example). If you plan to work with GAE, use what GAE provides and forget looking for a SQL-NoSQL holy grail. Existing solutions are inevitably limited and affect performance negatively.
Thank you for all the answers. To summarize the answers, currently only web2py and Django supports this kind of abstraction.
It is not about a SQL-NoSQL holy grail, using abstraction can make the apps more flexible. Lets assume that you started a project using NoSQL, and then later on you need to switch over to SQL. It is desirable that you only make changes to the codes in a few spots instead of all over the place. For some cases, it does not really matter whether you store the data in a relational or non-relational db. For example, storing user profiles, text content for dynamic page, or blog entries.
I know there must be a trade off by using the abstraction, but my question is more about the existing solution or technical insight, instead of the consequences.
I know the mismatch between Object Oriented Technology and the Relational Technology, generally here.
But I do not know the mismatch between MySQL and Python, and other tools, not just ORMs, to deal with the issue, missing in the latter article.
Questions:
How is the problem dealt between MySQL and Python?
Does App Engine's non-SQL makes Python work better together?
Are there some general tools, perhaps ORM, to deal with mismatches?
What are non-standard ways to deal with the problem?
Could you say that the nonSQL is a tool to make the object-oriented world of Python match the Relational world? Or does the new design totally avoid the problem?
ORM is the standard solution for making the object-oriented world of Python match the Relational world of MySQL.
There are at least 3 popular ORM components.
SQLAlchemy
SQLObject
Django's ORM.
As was once said on comp.lang.python ORM's are like morphine -- it can save you pain if you are really hurting, but if you use it regularly you will end up with really big problems.
It's not hard to build relatively low level interfaces between a relational database and an object model. It's extremely hard to migrate an automated ORM mapping to a new design after the fact. Only immature programmers try to simplify things that are not hard without looking ahead to the possible consequences that are extremely hard.
The google app engine mini-rdb-with-some-restrictions-removed is nice because it
only automates extremely simple stuff and forces you to think about the table layout
without pretending that it can all be done automatically.
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 1 year ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I have been using Turbogears 1 for prototyping small sites for the last couple of years and it is getting a little long in the tooth. Any suggestions on making the call between upgrading to Turbogears 2 or switching to something like Django? I'm torn between the familiarity of the TG community who are pretty responsive and do pretty good documentation vs the far larger community using Django. I am quite tempted by the built-in CMS features and the Google AppEngine support.
Any advice?
TG2 is built on top of Pylons which has a fairly large community as well. TG got faster compared to TG1 and it includes a per-method (not just web pages) caching engine.
I think it's more AJAX-friendly than Django by the way pages can be easly published in HTML or JSON .
2011 update: after 3 years of bloated frameworks I'm an happy user of http://bottlepy.org/
I have experience with both Django and TG1.1.
IMO, TurboGears strong point is it's ORM: SQLAlchemy. I prefer TurboGears when the database side of things is non-trivial.
Django's ORM is just not that flexible and powerful.
That being said, I prefer Django. If the database schema is a good fit with Django's ORM I would go with Django.
In my experience, it is simply less hassle to use Django compared with TurboGears.
I have been using Django for a year now and when I started I had no experience of Python or Django and found it very intuitive to use.
I have created a number of hobbyist Google App Engine apps using Django with the latest one being a CMS for my site. Using Django has meant that I have been able to code a lot quicker and with a lot less bugs.
Am sure you would have read from plenty of comparison between TurboGears and DJango on web.
But as for your temptation on CMS and GAE, i can really think you got to go DJango way.
Check these out, and decide youself.
Django with GAE
Django for CMS
Ive only got one question...is the app you are developing directed towards social networking
or customized business logic?
I personally find Django is good for social networking and pylons/turbogears if you really
want the flexibility and no boundaries...
just my 2c
TG2 seem much complicated and confusing, even for doing somewhat simple like a login page with multimple error messages
How to extend the Turbogears 2.1 login functionality
I think thats because of intemperance in modularity...
Django ORM uses the active record implementation – you’ll see this implementation in most ORMs. Basically what it means is that each row in the database is directly mapped to an object in the code and vice versa. ORM frameworks such as Django won’t require predefining the schema to use the properties in the code. You just use them, as the framework can ‘understand’ the structure by looking at the database schema. Also, you can just save the record to the database, as it’s mapped to a specific row in the table.
SQLAlchemy uses the Data Mapper implementation – When using this kind of implementation, there is a separation between the database structure and the objects structure (they are not 1:1 as in the Active Record implementation). In most cases, you’ll have to use another persistence layer to keep interact with the database (for example, to save the object). So you can’t just call the save() method as you can when using the Active Record implementation (which is a con) but on the other hand, you code doesn’t have to know the entire relational structure in the database to function, as there is no direct relationship between the code and the database.
So which of them wins this battle? None. It depends on what you’re trying to accomplish. It’s my believe that if your application is a mostly a CRUD (Create, Read, Update, Delete) application which no hard and complex rules to apply on the relationships between the different data entities, you should use the Active Record implementation (Django). It will allow you to easily and quickly set up an MVP for your product, without any hassle. If you have a lot of “business rules” and restrictions in your applications, you might be better with the Data Mapper model, as it won’t tie you up and force you to think strictly as Active Record does.