I want to create a database with SQLAlchemy ORM. At this moment, no web server is needed, so this solution is ideal. However, it is likely, that in future, we will want to add some web server functionality (using Django).
Are there any recommendations that I should do (when creating SQLAlchemy project) so that the possible migration to Django will be as easy as possible? (for example some naming conventions, using of multi column primary keys, and so on)
I know that we can use Django with existing database, but my question is rather what are the steps I can do at the start of SQLAlchemy project to make the future transition easiest it can be.
Related
I am using Django Rest Framework for backend development, where I have set up 2 environments. I have split settings files as required and both the environments have different DBs which are working fine, I am using Zappa(AWS lambda) for deploys, I was wondering is there an elegant way of migrating data(not models but data inside models say a few config changes) than preparing PostgreSQL DB rollouts, Could not find much on the internet, so asking here.
Please let me know if there are any questions.
I have a web app that I developed while learning back-end web development. I deployed it a while back and ended up getting some real users registered. Unfortunately, I wrote some smelly code and it is becoming very difficult to implement any new features without having to refactor large portions of the code base, so I am planning to rewrite the back-end.
The main issue I'm facing is whether there is a way to migrate the CustomUser model I've created to a new PostgreSQL database. Is this possible by simply recreating the same model in the new backend, then doing a pg_dump and restore?
If you don't have too many users, and you are using an identical model, it might be easiest to use the dumpdata management command on your old system, and use the resulting fixture to loaddata on your new system.
I have a lot of old vbscript webpages using Classis ASP. Those ASP pages have lots of different databases queries to different databases all inside a given .asp file. I want to write those in Python and use Django as the framework. Will I be able to do this? I'm not sure how to start after I install Django. Sure, I can make a demo work, but that's not what I'm after. I will use the normal database "things" in MySQL or PostgreSQL, but sooner or later I have to hit those other databases and bring them back into Django, using Django's templating and so on.
Will I be able to do this? How do I make a model that queries my legacy SQL Server and Oracle database and send that to the view? Am I "fighting the framework" to accomplish this?
Just to be clear. I am not interested in messing with the stock database that Django uses for it's settings. That can stay as it is. I want to use that part for plugins, security (ldap), etc.
Thanks.
You can query different databases in your ORM calls by leveraging the using statement: https://docs.djangoproject.com/en/1.5/ref/models/querysets/#using
This would allow you to set up as many database definitions as you need in settings.py, then specify which DB to query at the view level. That way, you wouldn't have to change your model definition should you decide to consolidate your databases, etc.
Have you reviewed the Django multiple databases documentation?
Django has a built-in Oracle back end, so that should be fairly straightforward.
SQL Server can work through django-pyodbc but I found it fairly painful to set up. If you already have a generally working ODBC connection to your legacy SQL Server database connection from your Django environment it's no big deal, but it took me some trouble to get things set up to where I could use tsql to connect to my SQL Server database.
I also had some trouble with Unicode data from the SQL Server database until I forced it to use the appropriate (later) version of TDS. I just needed it for a script or two, so I set the 'TDSVER' environment variable and left it at that, but in theory there are other places you can set that.
I am looking for a guide to migrate Django project to Google App Engine and use Google's datastore. The most of the guides I found were linked to Django-Appengine using Django-nonrel (but I want to use GAE's native support).
Going through GAE getting started guide, it says:
Google App Engine supports any framework written in pure Python that speaks CGI (and any WSGI-compliant framework using a CGI adaptor), including Django, CherryPy, Pylons, web.py, and web2py. You can bundle a framework of your choosing with your application code by copying its code into your application directory.
I understand that I won't be able to use some features of Django in that case (majorly the admin feature) and would also need to restructure the models.
From other reading, I also found that latest SDK of GAE now includes Django 1.3 on Python 2.5.
I tried to put all files from my Django application to a GAE project, but couldn't get it all to work together.
Please provide some basic guide using which I may migrate my Django project to Google App Engine's code.
Thanks.
For an existing Django app, using django-nonrel is the simplest approach; it is very popular so you should be able to find help with specific errors you get quickly.
Another approach is written up in this article: http://code.google.com/appengine/articles/pure_django.html -- it goes the other way, taking an App Engine app that uses Django for dispatch, templates, and forms, but not for models, and describes how to make it run in a native Django environment. Maybe you can glean some useful hints for your situation from it.
I've used django-nonrel, which behaves pretty much like django, except that operations with JOINs will return errors. I've basically worked around this by avoiding ManyToMany fields, and essentially building that functionality manually with an intermediate table.
So far I've ran into two problems with Django-nonrel:
1. No access to ancestor queries, which can be run in a transaction. There's a pending pull request for this feature though.
2. You can't specify fields that are not indexed. This could significantly increase your write costs. I have an idea to fix this, but I haven't done so yet.
(Edit: You CAN specify fields that are not indexed, and I've verified this works well).
2 (new). Google is pushing a new database backend called ndb that does automatic caching and batching, which will not be available with django-nonrel.
If you decide not to use django-nonrel, the main differences are that Django models do not run under App Engine. You'll have to rewrite your models to inherit from App Engine's db.Model. Your forms that use Django's ModelForm will need to inherit from google.appengine.ext.db.djangoforms instead. Once you're on App Engine, you'd have to port back Django if you ever take your app somewher else.
If you already have a Django application you might want to check this out. You won't work with App Engine's datastore but Google Cloud SQL might fit your needs.
According to this question:
Django on Google App Engine
The easiest way to get started with GAE/Django is with the Django non-rel bundle. However now that the latest Python/GAE SDK includes a build of Django, do we still need this?
What's the best-practice for getting started wth Django on GAE right now?
Thanks
Update: It seems that Web app2 is the easiest choice for new projects.
This guest article suggests that
"App Engine does come with some Django support, but this is mainly
only the templating and views."
non-rel is still seemingly your best bet. Although I'd caution you that further development and/or maintenance may not happen according to their blog.
Normal Django's models doesn't have a backend supporting GAE's datastore. Hence you can't use Django models, and hence, Django's model forms. What you'd have to do use use models derived from GAE's python db.Model(). Instead of using Django's ModelForm class for forms, you would use google.appengine.ext.db.djangoforms. Note, that's specifically for ModelForms, other forms work fine since they're not tied to the database.
I can think of two good reasons to use Django-nonrel:
1a) you have a existing project on Django. Using Django-nonrel would be the laziest way to go. Rewriting models to GAE's models isn't too hard, but it could be a small pain, especially if
1b) you use a lot of existing Django components, and you'd have to go through all of them to update the models and forms.
2) You want to hedge your bets against GAE. Using Django-nonrel will allow you to switch over to MongoDB with very little effort, since Django-nonrel has a functioning MongoDB backend. The current Django-nonrel maintainers seem to be more interested in MongoDB.
Having worked with Django-nonrel, I've so far run into some reasons why it may be a bad choice:
1) No support for ancestor queries. There's an outstanding pull request for this though. It won't be compatible with any other DB backend though.
2) ndb is coming out, and seems like it'll have a few more benefits, that likely won't see support on Django-nonrel.
If you do use GAE's native db API, the main benefit from Django would be the form validation. Otherwise, webapp2+jinja2+gae db.Models() would provide similar functionality to Django.