I'm thinking of hosting an app on app engine, and I already started building it in native django. Is it crazy to use djangoappengine (django-nonrel) for a production product? Is it proven?
It seems to be available at least since 2010 and acknowledged by Google. So I'd say it's pretty solid.
django-appengine is widely used in production by companies such as Potato London, have a look at their porfolio, you'll find some pretty solid stuff.
You do need to realize that there are quite substancial diferences with a vanilla Django SQL installation, especially in the ORM, many complex queries will not be available as JOINs are not supported natively. There are workarounds for most problems but they're a bit harder to wrap your head around if you never used non-relational databases or Datastore.
Make sure you read the documentation on Datastore and the django-appengine DB documentation and judge if it's worth the trouble.
Also worth mention these two packages from AllButtonsPressed that help a lot dbindexer and nonrel-search.
Related
Is Django-nonrel still active? I am interested on developing an e-commerce website that involves tons of catalogs and it seems like NoSQL is the best approach for this. I have background in Django but from what I found out, vanilla Django does not support NoSQL.
Enter the Django-nonrel as the alternative. However I am a bit concerned on the project continuity and community. Django-nonrel is a forked of Django 1.3, does this mean that it us outdated (since current Django is 1.5), or does it has its own circle and version after the fork?
In short, what is the status of Django-nonrel? Active?
This was recently discussed here:
http://www.reddit.com/r/django/comments/1cdrqs/using_mongodb_with_django_whats_the_status/
where the following stands out:
"It does not exist yet. And I'd strong recommend not using MongoDB unless you have a good use-case for it. Needing lots of reads/writes in some parts isn't enough to justify it IMO. MongoDB's read/write performance falls back down to earth once it's put in a real world scenario.
...
Disclaimer: I'm a dev working on a series of MongoDB apps that service hundreds of thousands of users and wish very much my predecessors just went with Postgres."
Yes it is, I am using for a year now and is working fine, the only downside, at least for me is that you can't do contains search.
If you want to change ideas please let me know.
django-nonrel is not active now, I´m testing the last version, it´s a django 1.6.11 fork
git+https://github.com/django-nonrel/django#nonrel-1.6
working with postgre and mongodb as DB engines simultaneously and it works
I'm trying to find any information if official django is going to support any noSQL DBMS, especially MongoDB. I found a fork of django 1.3 the django-nonrel (a fork of official django) and some other not very reliable projects (failures occur often, according to comments I found on the web). Is django going to support noSQL officially at all?
Perhaps, there are other ways to achieve your goals, besides going noSQL.
In short, if you just need dynamic fields, you have other options. I have an extensive writeup about them in another answer:
Entity–attribute–value model (Django-eav)
PostgreSQL hstore (Django-hstore)
Dynamic models based on migrations (Django-mutant)
Yes, that's not exactly what you've asked for, but that's all that we've currently got.
As you said, forked code is never the best alternative: changes take longer to get into the fork, it might break things... And even with django-nonrel, is not really Django as you loose things like model inheritance, M2M... basically anything that will need to do a JOIN query behind the scenes.
Is Django going to support NoSQL? As far as I know, there's no plans on the roadmap for doing so in the short run. According to Russell Keith-Magee on his talk on PyCon Russia 2013, "NoSQL" is on the roadmap but in the long term, as well as SQLAlchemy. So if you wanna wait, is going to take a long time, I'm afraid.
Anyway, even if it's not ideal, you still can use Django but use something else as a ORM. Nothing stops you from use vanilla Django and something like MongoDB instead of Django ORM.
Well, the title says most of it. I'm looking to develop a chat application that will hopefully become something more, and currently I'm considering my options for what I should build it on top of.
I've taken a look at Tornado with Redis as my primary option - Tornado, being a Comet server, is perfect for long polling to retrieve the messages on Redis, which I have the intention of using as both a persistent data store, as well as a message queue with its nifty subpub features.
However, I've also heard good things about Django, RabbitMQ, MongoDB and Orbited. JavaScript isn't a big problem for me, so Orbited's JavaScript support isn't too much of a boon.
Really, I'd probably be happy to develop on the route I've chosen for myself, but if there are any gaping deficiencies in my plan, I'd like some kind person to point them out before I find I've wasted months on this.
Since Javascript is not a problem for you and you need high-performance you should really consider Node.js. It's really fast for this kind of stuff.
It's fairly new project, but it already has a bunch of libraries. It also has already a package manager NPM like PIP (python) or Gem (Ruby).
Don't use Django for this. It should be possible at some level, but it is definitely not well suited for it. Tornado sounds like a great fit, so if that works go for it.
Have you ever considered Scala?
I agree with the rest of the people answering this question. If you need a high performance web server I would recommend you to take a look at Deft. Take a look at the benchmarks and the examples and see if it fits your needs.
Disclaimer: im a Deft committer
I want to create a website and I am confused which web framework to use. Please recommend me which framework is better: Django or Zope. I am using Python.
If you mean plain Zope2 by zope then I'd go for Django. Most interesting stuff in the Zope world takes place with either Plone or Grok (which is Zope3, which is actually quite different from Zope2).
Grok works nice with relational databases, Plone doesn't really, so if you depend on an RDBMS, either go with Grok or Django.
Zope and Plone have a rather steep learning curve so you'll get started more quickly with Django.
The largest downside about Django is, in my opinion, that it tries do do everything by itself (templating, object publishing, ORM, and so on) while there are many excellent existing components out there. If you want to be able to use your code / knowledge outside of the web framework you're using, consider Pylons or BFG
Many options, no clear answer, sorry :)
I have no idea what sort of website you're trying to create, so it's hard to recommend a specific framework.
I'd recommend getting through some tutorials to see which one you like best (There's also pylons and TurboGears to pick from).
Django seems to be the most popular starting kit these days though.
If your website is very hierarchical and needs fine grained permissions, I'd use Zope. (Don't use Zope if you intend to store your data almost exclusively in an SQL database.)
If you have large datasets that can be put into (sql)tables and need many forms, I'd use Django. (Don't use Django if you need very fine grained access control, and hierarchical data)
You see: both have their weaknesses and strengths (although I am only developing in Django these days. The Zope community seems to be a bit in dispute these days about the way it should develop)
Zope is dead. As is TurboGears, Pylons, BFG, Repoze, CherryPy etc.
Active and popular Python web frameworks include:
* django
* flask
* bottle
Big, medium and small. Take your pick.
Here is a good comparison of Django and Zope (and Rails)
http://cd-docdb.fnal.gov/cgi-bin/RetrieveFile?docid=2715;filename=Comparison.html;version=3
They preferred Django. I, personally, use Django too, so I don't know much about Zope.
Another good thing about Django is that they have very good documentation (though I don't know that of Zope). Many people praise that very much.
Also I found Django quite easy to use, and also they have a ready 'administrator panel', which allows quick web-oriented site management from the first steps. More important for me, however, is its fine integration with python and the simple organisation (in the link above they complained that Zope uses very much of its own features, while Django is closer to pure Python).
If you are starting from scratch I will suggest you should go for Django. You will get lots of features and suppost from django. Easy to debug and best suited for rapid developement. In the other hand, You should only choose Zope, if you have experienced developers familiar with Zope or have existing projects based on Zope and the cost of switching is too high for the potential value gain.
In zope's website it self it is written, It is no longer recommended to start new projects based on it, unless you are intimately familiar with the technology stack.
I've recently used Django for a very small CMS-style website. I was so impressed with how quick and easy it was to develop a Django project, that I'm now considering using it for a significantly larger project.
However, before I get excited about the idea, I just wanted to run it by someone who actually has developed a very large Django website (with many features, and high traffic).
Baring in mind that recently I have used mostly C# Asp.Net - Are there any pitfalls I should know about?
As mentioned, it really depends on what "large" and "complex" actually mean. If you're planning on building another eBay, the answer is "probably not".
This question is asked a lot. Frankly, there are plenty of answers out there. This thread is pretty good. There was also a very well attended presentation at DjangoCon this year on Scaling Django. It's up to you to architect your site so that it scales, regardless of what technology you use.
My answer would be: If your site is going to outgrow Django (or any other framework, for that matter), it's huge success and you'll probably have enough capital to hire a gigantic team to rewrite the entire thing.
It's going to depend a lot on exactly what you mean by "large" and "complex".
As far as "complex", take a look at Pinax. Tons of features all built out of simple Django apps hooked together and it's still considered a framework that you would use as a start towards building a social software site. But I'm sure you can still come up with some version of "complex" that doesn't mesh well with Django's architecture.
Handling large amounts of traffic and large datasets is a different matter. Ultimately, if you get large enough, Django's not going to handle it. But really, neither will any framework. Jacob-Kaplan Moss (one of the django devs) has a great article outlining the history of web development that led up to where Django is. He makes a pretty strong case for why Django or any other framework can't excel at both rapid development and massive scalability but why it's still worth starting with one. Basically, no two high traffic sites are going to have the same scalability issues: they will all need a custom approach that's specific to the exact type of data and traffic they have to deal with. But since it's hard to predict exactly where those bottlenecks are going to be, it's a good idea to start with a rapid development framework and start replacing components when you encounter the need.
I found this quite interesting to read: http://softwaremaniacs.org/blog/2008/02/24/why-offline-crashed-en/
There are a lot of interesting articles in this blog, but, unfortunately, they're all in Russian.
Added: And since that post Ivan did write MySQL backend supporting master-slave replication: http://softwaremaniacs.org/soft/mysql_replicated/en/