Hi Cal, Thanks. I'm always looking for more pain points about Django that could be improved.
Collin On Friday, December 12, 2014 1:05:02 PM UTC-5, Cal Leeming wrote: > > Hi Collin, > > Just a few comments; > > On Fri, Dec 12, 2014 at 5:42 PM, Collin Anderson <cmawe...@gmail.com > <javascript:>> wrote: >> >> 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. >> > > Custom models is (imho) still unnecessarily complex, something as simple > as not requiring a username field requires a lot of work. There have been > several instances where migrations had to be scraped due to weird edge > cases with 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. >> > > DRF has it's own problems and (again imho) does not solve the problems it > was originally designed to fix. Attempting to build anything beyond "out of > the box CRUD" requires hacky/unclean workarounds, with most of your time > spent fighting against the shortcomings of DRF rather than working with it. > > Building a clean RESTful API in Django is possible, but it requires a lot > of custom libs/hacks to make it work properly. For example, you have to > create your own method dispatcher/router, which in turn breaks > class/dispatch decorators due to the way those are loaded. Or you could > throw it all into a single class and split out the functionality using > get/post/put, but this is really unclean because each HTTP method is > essentially it's own view. Another way is to not use decorators of course. > Then you have partial form handling, which I already touched on in another > thread [1], so I won't repeat here. > > These are just a few examples of annoyances which hinder productivity. > That being said, Django is still quite good at a lot of things, and again > it comes down to "the right tool for the job". It's all about knowing the > strength/weaknesses of your options, and making an appropriate choice based > on your use case, making sacrifices dependant on your needs etc. > > [1] https://groups.google.com/forum/#!topic/django-users/pZCk4cFVcSI > > > >> 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> 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-creato >>>>> r-monty-widenius-wants-it-to-disappear-from-the-earth >>>>> [5] http://www.themukt.com/2014/09/11/reason-use-mysql-micha >>>>> el-widenius/ >>>>> [6] https://news.ycombinator.com/item?id=4076834 >>>>> [7] http://www.amazon.co.uk/The-Clean-Coder-Professional-Pro >>>>> grammers/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-outperform >>>>>> s-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_2rxbutrQN >>>>>> m%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/1fc80432-6623-413e-b2cb-8a2b1fd800d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
