I am in search for a extension that is similar to django_-volution.
The requirement is to alter the database, whitout deleting the wohle data.
I don't know, but for me, this is something so ordinary - doesn't django have a built-in function like that?
django_evolution is still in working progress and has some bugs, so i want something that is stable and maybe has more options. Especially to write own mutations seems a little bit complex for me.
Does anybody know something similar?
Thanks for all answers
You're looking for South. It's currently the de-facto schema and data migration plugin for Django. I believe there have been talks about adding it to the core of Django. It has a bit of a learning curve but you seriously want to take the time and learn it.
You'd like something to perform 'migrations' a la rails, correct? The best known and most stable project is South, as far as I know. It offers "intelligent schema and data migrations for Django projects".
http://south.aeracode.org/
Personally, I just alter my model, and make the changes through the database command line client.
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.
I'm build a Django app with Neo4j (along with Postgres), I found this Django integration called neo4django, I was wondering if it's possible to use neo4restclient only, like, what would be the disadvantages of not using Neo4django? Does using neo4-rest-client only, give me more flexibility?
When I was creating my models with Neo4Django, it seemed that there is no difference between modeling a graph db and relational db. Am I missing anything?
Thanks!
You can absolutely go ahead with neo4j-rest-client or py2neo, without using neo4django. In the same way, you can use any other database driver you'd like any time using Django, any REST client, etc.
What'll you lose? The model DSL, the built-in querying (eg, Person.objects.filter(name="Mohamed")), the built-in indexing, and the Lucene, Gremlin and Cypher behind that. Some things will be much easier- like setting an arbitrary property on a node- but you'll need to learn more about how Neo4j works.
You'll also lose some of the shortcuts Django provides that work with neo4django, like get_object_or_404() and some of the class-based views that work with querysets.
What'll you gain? Absolute power over the DB, and an easier time tweaking DB performance. Though neo4django isn't nearly as good a lib as some traditional ORMs in the Python sphere, the trade-off of power vs provided ease is similar.
That said, the two can work together- you can drop down from neo4django to the underlying REST client nodes and relationships anytime. Just use model_instance.node to get the underlying neo4j-rest-client node object from a model, and from neo4django.db import connection to get a wrapped neo4j-rest-client GraphDatabase.
On whether you're missing something: neo4django was written to re-use a powerful developer interface- the Django ORM- so it should feel similar to writing models for Postgres. I've written a bit about that odd feeling in the past. I think part of the problem might be that the lib doesn't highlight the graph terminology new graph-interested devs expect- like traversals and pattern matching- and instead dresses those techniques in Django query clothing.
I'd love your thoughts, or to know anything you'd like the library to do that it isn't doing :) Good luck!
I've been using south but I really hate having to manually migrate data all over again even if I make one small itty bitty update to a class. If I'm not using django I can easily just alter the table schema and make an adjustment in a class and I'm good.
I know that most people would probably tell me to properly think out the schema way in advance, but realistically speaking there are times where you need to immediately make changes, and I don't think using south is ideal for this.
Is there some sort of advanced method people use, perhaps even modifying the core of Django itself? Or is there something about south that I'm not just grokking?
I really hate having to manually migrate data all over again even if I make one small itty bitty update to a class.
Can you specify what kind of updates? If you mean adding new fields or editing existing ones then obviously yes. If you mean modifying methods that operate on fields then there is no need to migrate.
I know that most people would probably tell me to properly think out the schema way in advance
It would certainly help to think it over a couple of times. Experience helps too. But obviously you cannot foresee everything.
but realistically speaking there are times where you need to immediately make changes, and I don't think using south is ideal for this.
Honestly I am not convinced by this argument. If changes can be deployed "immediately" using SQL then I'd argue that they can be deployed using South as well. Especially if you have automated your deployment using Fabric or such.
Also I find it hard to believe that the time taken to execute a migration using a generated script can be significantly greater than the time taken to first write the appropriate SQL and then execute it. At least this has not been the case in my experience.
The one exception could be a situation where the ORM doesn't readily have an equivalent for the SQL. In that case you can still execute the raw SQL through your (South) migration script.
Or is there something about south that I'm not just grokking?
I suspect that you are not grokking the idea of having orderly, version-controlled, reversible migrations. SQL-only migrations are not always designed to be reversible (I know there are exceptions). And they are not orderly unless the developers take particular care about keeping them so. I've even seen people fire potentially troublesome updates on production without even pausing to start a transaction first and then discard the SQL without even making a record of it.
I'm not questioning your skills or attention to detail here; I'm just pointing out what I think is your disconnect with South.
Hope this helps.
I'm trying to solve the relational model in order to make a Django app.
I't will be something like a McDonald's crew scheduler. I mean the grid with colored pins marking who will be working at a given hour a given weekday.
I did try to Google out some example, but I didn't find anything. I need some theory/bibliography in order to build up my model and code it into my app.
Thanks in advance
From the short description, you probably wouldn't have just one model in your app.
From your question I'm assuming you don't have a lot of experience with databases... Here are a few suggestions:
Start here because if you don't understand the basic principles of database design, foreign keys, one-to-one, one-to-many, many-to-many, etc etc etc; you will have a hard time designing your Django models.
It would be nice to learn SQL too. Django models are supposed to insulate you from it, but in reality it is using SQL underneath and knowing SQL will enable you to check and fix performance issues in the future. There are some resources online too. And if you are using SQLite, learn its syntax too.
The above is stuff that you will be able to reuse regardless of the web framework you end up with. Django, Rails, the next big thing... whatever.
Study other people's data models. Here are several different ones - maybe you can find the one you are looking for (employee shifts? shift scheduling?).
Then read the basic django model documentation and really understand it. What django models are doing is mapping python objects to relational database tables (ORM is the acronym; Object Relational Mapping) and this article may very well help you in coming up with good designs.
Don't get discouraged. Everybody had to start somewhere.
Hope you find all you need. Have fun with Django.