Hi, Re: the hacker news thread, (sorry for getting a little off topic,) I just wanted to mention a few places where we've tried to improve some of those things recently: - The ORM is still slow, but we've added prefetch_related() and improved select_related() which allows you do use fewer queries. - We've pulled out some of components into separate projects: django-localflavor, django-contrib-comments, django-formtools, and I imagine more in the future. - You can now use custom user models. - We're working on an official public API for the model._meta internals and working towards components only using that. It also means it will be easier to use non-django models in the admin. - We're working on de-coupling django templates, allowing them to be used on their own, and making it much easier to use other template engines like Jinja2. - There's are also quite a lot of people using django-rest-framework for creating REST apis, which was one thing the thread said django was not good at.
Collin On Wednesday, December 10, 2014 3:21:07 PM UTC-5, Cal Leeming wrote: > > If you're using Django, then there isn't really an alternative, as it's > really a key selling point of Django. > > Some people recommend SQLAlchemy, but I dislike that even more for it's > over-engineered complexity. > > Peewee [1] shows some good potential, but I haven't tried it for myself > yet. > > As for why I dislike the Django ORM, many of the technical reasons are > already explained (in detail) in that thread [2] I mentioned before, but a > lot of it comes down to personal taste and opinion of what matters most > about an ORM etc. > > Cal > > [1] https://github.com/coleifer/peewee > [2] https://news.ycombinator.com/item?id=4076834 > > On Wed, Dec 10, 2014 at 7:17 PM, Artie <giliar...@gmail.com <javascript:>> > wrote: > >> Can you please advise why actually you hate Django ORM and what should be >> considered instead of it? >> >> суббота, 6 декабря 2014 г., 23:18:06 UTC+2 пользователь Cal Leeming >> написал: >>> >>> Hi Artie, >>> >>> First, I would strongly recommend reading some of the work by David >>> Mytton at Server Density, he and his team have been using MongoDB >>> extensively for many years and they have shared a lot of their insight [1]. >>> It's also worth mentioning that Postgres has support for JSON field type >>> [2] which satisfies many of the use cases for document store, though I >>> haven't finished my own experiments yet so can't comment on comparative >>> performance/functionality. >>> >>> It's industry knowledge that MySQL is bleeding out, rapidly [3] [4]. At >>> this point, I introduce you to Monty and his creation MariaDB [5]. Although >>> I would agree with Russell on many of the points he's made about MySQL, >>> it's hard not to have respect for the work that Monty and his team have >>> done previously on MySQL, and the vision that is now MariaDB. I would >>> strongly recommend you spend some time looking into this yourself, read as >>> many comparison articles as your eyes will allow, and come to your own >>> conclusions. >>> >>> I have built numerous "large scale" systems with a variety of >>> technologies.. Sphinx, ElasticSearch, MongoDB, MySQL, CouchBase, Redis. >>> I've also spent many years battling with MongoEngine and have learnt to >>> hate it, as much as I now hate the Django ORM. So, unless you are edging >>> towards terabytes of data, assuming you are using SSDs and high memory >>> nodes, then the impact of your choice will probably be negligible. And if >>> you are using the Django ORM, then you are even less likely to reap any of >>> these benefits out of the box [6] There are many different reasons for >>> choosing one over the over, and you should assess this based on your own >>> use case/needs/skills, rather than religious bias. >>> >>> Determine your use case and test all viable options, otherwise you could >>> be avoiding something for the wrong reasons. You can build *beautiful* >>> things with all these different technologies, and it's actually the mindset >>> which matters the most [7]. Don't just settle for what others are telling >>> you, try for yourself and come to your own conclusions, only then can you >>> be sure. It's also a good way to gain in-depth knowledge about how these >>> technologies work, which can be invaluable. >>> >>> Cal >>> >>> >>> [1] https://blog.serverdensity.com/mongodb/ >>> [2] http://www.postgresql.org/docs/9.3/static/datatype-json.html >>> [3] http://www.theregister.co.uk/2012/11/29/monty_oracle_eu_promises/ >>> [4] http://www.computing.co.uk/ctg/news/2271011/mysql- >>> creator-monty-widenius-wants-it-to-disappear-from-the-earth >>> [5] http://www.themukt.com/2014/09/11/reason-use-mysql-michael-widenius/ >>> [6] https://news.ycombinator.com/item?id=4076834 >>> [7] http://www.amazon.co.uk/The-Clean-Coder-Professional- >>> Programmers/dp/0137081073 >>> >>> >>> >>> On Sat, Dec 6, 2014 at 12:26 AM, Russell Keith-Magee < >>> rus...@keith-magee.com> wrote: >>> >>>> >>>> On Fri, Dec 5, 2014 at 8:56 PM, Artie <giliar...@gmail.com> wrote: >>>> >>>>> Good day, Community, >>>>> >>>>> I'm looking for advise on MySQL & MongoDB usage so please let me take >>>>> your time to describe the situation. >>>>> >>>>> I came to work on e-commerce shop of electrical components with about >>>>> 10 millions of products. Now all of it stored in awful structure of >>>>> tables >>>>> in MySQL. Products stored in 10 small tables, each of them represents >>>>> individual manufacturer of products and 1 generalized table, where all 10 >>>>> millions of goods is stored. Those big table serves Sphinx search to >>>>> implement search on site. >>>>> All these products being crawled from several APIs and sites on web, >>>>> so this shop is kind of authorized reseller in our region. >>>>> >>>>> The case is that we have to update all products daily and parsing >>>>> with updating of products takes very long time. >>>>> >>>>> I have an idea to start using MongoDB to update and store products and >>>>> as I think it might take less time than same in MySQL. First question: Am >>>>> I >>>>> correct with this statement? >>>>> >>>>> Browsing web I've found that some recommend using pymongo, avoiding >>>>> django rather than mongodb for django. So for your opinion is this >>>>> statement correct? >>>>> >>>>> Also it will be highly highly appreciated if you can share your >>>>> personal use experience with MongoDB and any information you think be >>>>> useful. >>>>> >>>> >>>> Hi Artie, >>>> >>>> Can I make an alternate suggestion? Get a real database. >>>> >>>> In all honesty, I've never heard anyone in the Django community express >>>> a deep love of MySQL or MongoDB. I know people who use MySQL, but when >>>> they >>>> admit that, they say "Yeah, I know, but the customer required it" or >>>> "Yeah, >>>> I know, but at the time we started it was the only thing Amazon >>>> supported". >>>> As for MongoDB, the sentiment is usually "... and that was our first >>>> mistake.". >>>> >>>> Personally - I have very little time for MySQL. It gets a number of key >>>> design decisions wrong (for example, InnoDB's implementation of row >>>> referential integrity is *demonstrably* incorrect). It has some default >>>> behaviours that beggar belief (e.g., on MyISAM, by default, a row with a >>>> "WHERE field IS NULL" clause that matches no results, and the previous >>>> statement was an insert, the query will not return no results, but the >>>> primary key of the last row inserted. By design [1][2]). And MySQL's usage >>>> of indexes is woefully naïve - to the point where "performance optimising >>>> for MySQL" often means "Roll out the results of an inner query and pass >>>> them in as arguments, rather than just using a subquery". >>>> >>>> [1] https://code.djangoproject.com/ticket/14661 >>>> [2] https://groups.google.com/forum/#!topic/django- >>>> developers/1BgLit316XA >>>> >>>> And then you have MongoDB - a database that exists, as far as I can >>>> make out, to overcome the deficiencies in MySQL. If you'd just started >>>> with >>>> a real database, you wouldn't have hit the problems with MySQL, and you >>>> wouldn't have to go looking for an exotic solution to overcome those >>>> problems. >>>> >>>> If you're looking for performance, you're going to get much better >>>> performance out of PostgreSQL, for the same price you paid for MySQL, with >>>> the added benefit that PostgreSQL developers appear to have actually >>>> consulted the SQL specification when they implemented their database. They >>>> also have a query planner that will actually *use* indexes, instead of >>>> just >>>> keeping them for decoration like MySQL does. >>>> >>>> If you're looking for a "schemaless" data store - well, PostgreSQL >>>> hstore fields [3] have you covered. To the extent that people have >>>> actually >>>> developed "MongoDB in PostgreSQL" [4]. And those stores outperform MongoDB >>>> [5]. >>>> >>>> [3] http://www.postgresql.org/docs/9.0/static/hstore.html >>>> [4] https://github.com/torodb/torodb >>>> [5] http://blogs.enterprisedb.com/2014/09/24/postgres- >>>> outperforms-mongodb-and-ushers-in-new-developer-reality/ >>>> >>>> So - in all honesty, I'd start by reconsidering your initial >>>> assumptions. >>>> >>>> Yours, >>>> Russ Magee %-) >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to django-users...@googlegroups.com. >>>> To post to this group, send email to django...@googlegroups.com. >>>> Visit this group at http://groups.google.com/group/django-users. >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/django-users/CAJxq84-FKrcBeB5joYTAP97dreo5cDmu_ >>>> 2rxbutrQNm%3DAFru3g%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/django-users/CAJxq84-FKrcBeB5joYTAP97dreo5cDmu_2rxbutrQNm%3DAFru3g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/4490f8d4-7a47-4c5b-acdf-42b46eca9b6c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
