[Django] Python ORM database

[Chris89]

Goede avond,

Voor een project van mezelf wil ik een script maken in Python. Dit script moet een database aanroepen en dit zo universeel mogelijk te houden wil ik doen via de ORM module van Django.

Deze is modulair opgebouwd dus volgens mij mogelijk om deze eruit te halen zonder dat ik heel Django moet "heel" installeren.

Om dit aan de gang te krijgen heb ik dit voorbeeld gebruikt: http://stackoverflow.com/a/938373
Op zich ben ik dus al aardig op weg volgens mij.

Nu loop ik alleen vast op de volgende foutmelding:

File "manage.py", line 8, in <module>
from django.core.management import execute_from_command_line
ImportError: No module named django.core.management

Ik draai trouwens een Ubuntu laatste versie commandline met Python 2.7.2 en wil aan de gang met de laatste versie van Django.

Om dit op te lossen heb ik al heel Google afgezocht maar ik alleen maar bij uit om heel Django te installeren en dat zie ik eigenlijk niet zo goed zitten. Nu is de vraag in welke richting moet ik zoeken om dit op te lossen? Ik heb het idee dat hij opzoek is naar een file die hij niet kan vinden...

[ Voor 0% gewijzigd door Chris89 op 17-04-2012 23:58 . Reden: spelfouten eruit ]

[Styxxy]

Je moet er voor zorgen dat je alle referenties hebt die hij nodig heeft. Ik zie het probleem niet echt om bijvoorbeeld heel Django te installeren. Oké, je hebt dan te veel, maar dat maakt op zich niets / weinig uit.

[Chris89]

Het punt is als je heel django moet installeren dat het te veel word en als je het op een ander systeem wil draaien weer heel django moet installeren.... Dat wil ik dus voor zijn en alleen de bestanden die nodig zijn voor ORM/Database eruit halen. Weet trouwens dat er programma's zijn die al alleen die libary's eruit hebben gehaald... Helaas kan ik zo snel niet op een naam komen maar daar zal ik even naar moeten kijken.

Wat bedoel je referenties? Je verwijzingen naar files zeker?

[RobIII]

Doe eens gek en kijk eens naar je foutmelding: "File "manage.py", line 8...". Tien tegen één dat daar een file ge-include wordt die jij denkt "niet nodig te hebben". Dit soort zaken zul je, als je ergens een "stuk uit wil slopen/trekken" allemaal, en ja, stuk-voor-stuk, moeten gaan fixen met het handje. Weet je héél zeker dat je al die moeite wil gaan doen voor zo'n piepklein "voordeeltje"?

Sterker: ik durf stellen dat 't een nadeel is. Waarom? Nou, 1) elke keer als Django een nieuwe versie uitgeeft kun jij je "klusje" opnieuw gaan zitten doen, 2) je breekt meer dan je waarschijnlijk vermoedt, daar blijf je steeds tegenaan lopen tijdens je 'project', 3) alles wat nu georganiseerd is heb je straks verspreid over je "eigen" files overal ingefrot staan, 4) ...ga zo maar door.

[edit]
Code van Django er even bij gepakt... en, joh, wat staat daar?

Python: manage.py

    from django.core.management import execute_from_command_line

Tjemig, waar zou die foutmelding toch vandaan komen?
Als je nou eens een foutmelding leest (liefst begrijpend lezen) voordat je "heel google afzoekt"...

Chris89 schreef op dinsdag 17 april 2012 @ 23:56:
Ik heb het idee dat hij opzoek is naar een file die hij niet kan vinden...

Echt?

Hoe je 't oplost? Ik vermoed execute_from_command_line uit django.core.management "slopen" en ergens in je eigen code frotten. En dat, elke keer weer, voor elke functie die je tegen komt waar 'ie over zeurt.

[edit2]
Om even te quoten uit je vorige topic:

Chris89 schreef op dinsdag 17 april 2012 @ 14:56:
Django is modulair opgebouwd dus dat wil zeggen dat je er delen uit kan halen.

Ik denk dat je dat wat té letterlijk neemt

Wat je overigens, in fairness, al hebt bijgesteld in dit topic naar:

Chris89 schreef op dinsdag 17 april 2012 @ 23:56:
Deze is modulair opgebouwd dus volgens mij mogelijk om deze eruit te halen zonder dat ik heel Django moet "heel" installeren.

[ Voor 90% gewijzigd door RobIII op 18-04-2012 01:16 ]

[djc]

Misschien makkelijker om gewoon SQLAlchemy te gebruiken?

[Chris89]

RobIII schreef op woensdag 18 april 2012 @ 00:47:
Ik denk dat je dat wat té letterlijk neemt

Wat je overigens, in fairness, al hebt bijgesteld in dit topic naar:

[...]

Wil niet lullig doen maar includes heeft python niet... Je bedoelt imports volgens mij.
Na een nacht er over te hebben slapen is het inderdaad wel zo dat je meer kapot maak dan dat je direct heel Django installeer.

Als je bij Django alleen imports wil installeren zonder alle examples enzovoort is dat mogelijk? Ben niet zo goed thuis in Django namelijk. Als dit kan dan is er al een hoop troep uit Django wat je niet gebruikt.

djc schreef op woensdag 18 april 2012 @ 14:59:
Misschien makkelijker om gewoon SQLAlchemy te gebruiken?

SQLAlchemy is geen optie want deze ondersteunt alleen SQL en wil ook Postgres en SQLlite niet uitsluiten.

[RobIII]

Chris89 schreef op woensdag 18 april 2012 @ 15:48:
[...]


Wil niet lullig doen maar includes heeft python niet... Je bedoelt imports volgens mij.

Tomato, tomato. De strekking is meer dan duidelijk lijkt me.

[Nvidiot]

Chris89 schreef op woensdag 18 april 2012 @ 15:48:
[...]
SQLAlchemy is geen optie want deze ondersteunt alleen SQL en wil ook Postgres en SQLlite niet uitsluiten.

Uhm... http://docs.sqlalchemy.org/en/latest/dialects/index.html Daar staan Postgres en SQLite toch echt bij?

[truegrit]

Je gaat inderdaad helemaal de verkeerde kant op. SQLAlchemy is ideaal voor jou situatie, maar omdat je geen enkele moeite doet er iets over te lezen zit je nu omslachtig te doen.

[Sh4wn]

Misschien een beetje hard, maar je hebt volgens mij echt geen idee waar je het over hebt?

Ja Django is modulair, in de zin van dat je 'webapplicaties' (denk aan een forum, blog, gallery) makkelijk kan hergebruiken voor meerdere sites. Verder is de ORM van Django heel erg geintegreerd in de rest van de Django Core, dus ik denk niet dat je er veel mee opschiet om de ORM er uit te slopen.

Verder werd inderdaad SQLAlchemy al aangeraden, een ORM die ook veeeeeeeeel beter is dan die van Django. SQLAlchemy heeft ook ondersteuning voor PostgreSQL, MySQL, SQLite, en nog een aantal.

Wat jij met het statement "SQLAlchemy is geen optie want deze ondersteunt alleen SQL" bedoelt, is dan ook een onoplosbaar raadsel. SQL is een gestandaardiseerde taal om databasen te queryen. PostgreSQL, MySQL en SQLite ondersteunen allemaal deze standaard (al zijn er hier en daar wel wat verschillen). Wat SQLAlchemy doet is simpel gezegd een SQL query genereren en versturen naar de database, aan de hand van de functies die jij aanroept in de code. Hierbij houdt SQLAlchemy ook rekening met de verschillen tussen de verschillende database dialecten.

Voordat je een ORM fatsoenlijk kan gebruiken, moet je weten hoe SQL zelf werkt. Anders krijg je dit soort dingen:
http://mattiasgeniar.be/2...itely-worse-than-bad-sql/

[Kajel]

Sh4wn schreef op woensdag 18 april 2012 @ 17:09:

Voordat je een ORM fatsoenlijk kan gebruiken, moet je weten hoe SQL zelf werkt. Anders krijg je dit soort dingen:
http://mattiasgeniar.be/2...itely-worse-than-bad-sql/

De schrijver probeert valide punten te maken, maar faalt gigantisch omdat hij de ORM's die hij noemt als "slecht" schijnbaar totaal niet onderzocht heeft. De codevoorbeelden die hij geeft, en de uiteindelijke werking daarvan, komen in ieder geval totaal niet overeen met hoe Doctrine het doet. Of je nou van ORMs houdt of niet, Doctrine optimaliseert in de meeste eenvoudige tot semi-complexe situaties, je queries beter dan dat je dat als gemiddelde SQL gebruiker zelf zou kunnen doen.

[Sh4wn]

Kajel schreef op donderdag 19 april 2012 @ 11:44:
[...]

De schrijver probeert valide punten te maken, maar faalt gigantisch omdat hij de ORM's die hij noemt als "slecht" schijnbaar totaal niet onderzocht heeft. De codevoorbeelden die hij geeft, en de uiteindelijke werking daarvan, komen in ieder geval totaal niet overeen met hoe Doctrine het doet. Of je nou van ORMs houdt of niet, Doctrine optimaliseert in de meeste eenvoudige tot semi-complexe situaties, je queries beter dan dat je dat als gemiddelde SQL gebruiker zelf zou kunnen doen.

Ik ben het ook niet volledig met hem eens, sterker nog, ik ben best wel een fan van ORM's, maar goed, ik vind dat hij wel een punt heeft qua gebruik: je kan je ORM alleen goed gebruiken als je weet wat hij ongeveer zou moeten genereren (bijv. bepaalde join). Aan de hand van jouw idee wat het moet genereren, gebruik je de juiste constructies/functies van je ORM.

Van de Django ORM weet ik bijvoorbeeld dat die zulke constructies als in de bovenstaande link niet zou optimaliseren => gebruik select_related()

[t_captain]

Paar opmerkingen:
1. django hoe je niet te installeren. Je kunt gewoon de tar.gz uitpakken op de gewenste plek in je workspace en zorgen dat je pythonpath goed staat (zodat de directory django/ aanwezig is in een directory die in je pythonpath staat)
2. je kunt aardig slopen als je alleen de ORM wilt gebruiken. volgens mij hoed je vooral django.core en django.db te houden en kan de rest weg.
3. als je alleen ORM wilt hebben, zou je eventueel een andere library kunnen overwegen. Storm bijvoorbeeld.

[Kajel]

Sh4wn schreef op donderdag 19 april 2012 @ 16:23:
[...]


Ik ben het ook niet volledig met hem eens, sterker nog, ik ben best wel een fan van ORM's, maar goed, ik vind dat hij wel een punt heeft qua gebruik: je kan je ORM alleen goed gebruiken als je weet wat hij ongeveer zou moeten genereren (bijv. bepaalde join). Aan de hand van jouw idee wat het moet genereren, gebruik je de juiste constructies/functies van je ORM.

Van de Django ORM weet ik bijvoorbeeld dat die zulke constructies als in de bovenstaande link niet zou optimaliseren => gebruik select_related()

Absoluut mee eens! Ik vind dat je SQL eerst goed onder de knie moet hebben, op gevorderd niveau, voordat je een ORM gaat gebruiken. Zo kun je het ORM zelf "bijsturen" wanneer je ziet dat iets niet optimaal gebeurt. Django ORM ben ik niet in thuis, want ik ben pas 8 weken geleden begonnen met Python, maar als je weet dat een ORM bepaalde zaken niet optimaliseert, kun je voor die gevallen beter native SQL inzetten