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!
Related
I'm just wondering what is exactly the functionality that haystack provides and if I need it.
I mean the search and indexing is done by whoosh. As far as I can tell, haystack is just offering ready made views, and forms. If I want to write my own form and views do I still need haystack?
Am I missing something?
P.S. I don't plan to use any other search engine than whoosh so I also don't need haystacks's multiple search engine wrapping.
Besides views, forms and a search engine-agnostic layer, the other powerful thing about Haystack is its ability to map Django models to something the search index understands. Using Haystack, you can easily specify which fields in a model should be indexed and how (see the SearchIndex API - http://django-haystack.readthedocs.org/en/latest/searchindex_api.html).
Once you have done that, you can then leverage the built-in management commands to (re)index your data when required.
It also comes with some nice templatetags to help present search results, like highlighting the matching bits.
Is there a particular reason that you don't want to use Haystack? It is a pretty non-intrusive plugin that lets you use as much of it as you need, and makes it easy to use more advanced functionality when you need it later down the road. In one of the sites I built, I only used the SearchIndex and SearchQuerySet APIs; I built my own views and forms. Ultimately, if you end up writing your own indexing and searching code, views and forms, you have basically re-written a large part of Haystack, in which case, you may want to consider using something that is in use out there and reasonably well tested.
That said, I have rolled my own 'Haystack' like layer in another project, mainly because the data source didn't map to the Django ORM. In that case, I wrote my own indexing scripts, and used PySolr to interface with my Apache Solr instance.
Given that Whoosh is written in Python, I'd assume it has a decent Python interface, so it shouldn't be too hard to do. I would only do it if there's something special about your scenario though.
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 am working on a Google App Engine application and I am relatively new at this.
I have built an app already in Django and have a model using a field type of ManyToMany.
I am aware that django-nonrel does not support many-to-many field types of Django. So I am considering using ListField instead.
Questions:
- What is the implication of using ListField instead of ManyToMany?
- I am aware that this means that Django's JOIN API cannot be used. But what does this mean for my app?
- Am I going to have problems when it comes to doing a search for something in a many-to-many field?
Apologies if these are programming 101 questions. I'm a designer trying to get my head around development.
Thanks
Well as you probably know, you will be spanning the relationship more manually.
Django cannot help quite as much as when using ManyToMany, but it should not be that big a problem.
Depending on the complexity of the relationship, you might want to consider building a model just for this purpose.
I have never used that approach on GAE, since IMO its only valid when an object has alot relations (more than 50 I would say) or when the lookups you plan to do, will benefit from this. Maybe because they start at either end of the relationship with equal frequency or it would be nice to be able to loop over the relationships to display them or something along those lines.
Last time I made something on GAE I used the ListField (or ListProperty as it was known then) since most of the objects only had about 20 related objects and the lookups would rarely go the other way.
So all in all, its not a big deal and I don't remember it as any kind of a pain to work with/around.
Hope this was helpful despite it being rather "IMO"
The Django orbit integration methods I've seen in quick google searches don't seem to carry Django abstractions, like "request.user" with them. "request.user" is particularly important, since I am not going to (potentially incorrectly) re-implement session handling (this sounds like it could cause bad security bugs).
Alternatively, should I use a different server? I'd prefer to use stable, mature, popular software, that will be maintained and improved. Orbit and Django seem to be qualified.
If you're looking to "integrate Django and Orbited", you might have a look here: http://github.com/clemesha/hotdot which is a very complete (but not yet polished) example of what I think you are looking for.
In particular, the example includes Authentication using Django models from the Orbited process (more specifically, Twisted Cred + Django models), as well as filtering and modifying of in-transit Orbited messages. In the example you'll find that you basically get the "request.user" object because the "request.user" object can be accessed by the cookie that Django sets + database calls using django.contrib.sessions.models.Session model object.
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.