Wszystko

Wszystkie

Archiwum

Spofity
Spofity
  • 0
Mam dwa modele, powiedzmy model1 i model2. Te modele mają dwa wspólne pole i tylko ich potrzebuję w tym przypadku: name i slug. Mam stworzyć widok, w którym będzie 1000 obiektów z paginacją.
Przy małej ilości danych zrobiłem to w ten sposób:

data = list( sorted( chain( model1.objects.all(), model2.objects.all()) ) )
a potem wrzucałem to do Paginatora (paginator = Paginator(data, 1000)
WhiskyRomeo
WhiskyRomeo
  • 4
@jaroslaw-stadnicki: @Jurigag: Nie jest słabe. Baza danych której schemat został przemyślany i zaprojektowany przez specjalistę w zasadzie zostaje otwarta na każdego deva który nie ma pojęcia jak wydajnie zapytać o dane. To brak izolacji. Zupełnie jak mutowalna klasa z publicznymi zmiennymi. Odpowiedzialność w jaki sposób zmieniane są dane powinien być po stronie bazy danych i nikt inny nie powieniem tam grzebać. Ten pattern dziala tylko jak macie w
  • Odpowiedz
wildcat89
wildcat89
  • 4
Cześć Mirki,
od jakiegoś czasu tworzę podcast Backend na Froncie, w którym rozmawiam z gośćmi na tematy programistyczne (zwykle około .NETowe)
Dzisiaj pojawił się odcinek numer 6, w którym razem z Michałem Białeckim odpowiemy na pytanie Dlaczego używamy Entity Framework?

Rozmawialiśmy o tym:
Co to jest orm
  • Odpowiedz
chester
chester
  • 1
SQLAlchemy ORM vs Peewee - czego teraz warto używać?
Pytam, bo SQLAlchemy ma już swoje lata, a Peewee wygląda na świeższy, acz dojrzały projekt.

Czy jedno lub drugie ma jakieś istotne różnice, które mogą mnie zatrzymać w późniejszym czasie?
Póki co wiem o kiepskim mechanizmie migracji w Peewee.

#python #orm #kiciochpyta
opalczynski
opalczynski
  • 2
@chester zależy do czego; z tego co kojarzę to peewee zawsze miał być mały i prosty w założeniach. Z tego też względu bym go wybierał przy mniejszych tematach - mniej skomplikowanych, gdzie warstwa danych nie jest wymagająca - i nie dlatego, że się nie da inaczej - ale tak raczej just-in-case żeby się nie okazało, że później nie można. SQLAlchemy zawsze przerażał liczbą możliwych opcji - i ten się wciąż sprawdzi
  • Odpowiedz
chester
chester
  • 0
@opalczynski: no tak, DRF daje radę. Mi się zachciało spróbować GraphQL, stąd też chciałem spróbować odejść od Django, bo tak naprawdę jedynym elementem Django, którego potrzebuję byłby jego ORM. A kusi mnie też spróbować ASGI :)

Ale kto wie, może wrócę jeszcze z tym do Django :)
  • Odpowiedz
dwuitownik
dwuitownik
  • 14
Jakim zwierzęciem trzeba być by niszczyć miejskie rowery? Są w Olsztynie około trzech miesięcy, a już bardzo często trafiam na uszkodzone. Ostatnio miał wyłamaną nóżkę, dziś połamany koszyk, normalnie w Olsztynie jak w lesie, albo gorzej. Jedna z najlepszych rzeczy, jakie to miasto zrobiło, ale nie, i tak trzeba #!$%@?ć, bo nie moje.

#olsztyn #wpolscejakwlesie #orm #rower
dwuitownik - Jakim zwierzęciem trzeba być by niszczyć miejskie rowery? Są w Olsztynie...

źródło: comment_UigOAXa1sN6bACIFp2Em7o46IFP49h9d.jpg

Pobierz
BooB
BooB
  • 2
@dwuitownik: ostatnio kolega przez te rowery niezłego dzwona zaliczył, w trakcie jazdy kierownica mu centralnie odpadła, nie wiem czy ktoś zostawił taki rower rozwalony, czy specjalnie odkręcił kierownicę, ale koleżka nieźle wywalił orła. Policja też była. Nie wiem jeszcze jak ta sprawa się zakończyła :/
  • Odpowiedz
PrawyKuba
PrawyKuba
  • 1
@safuka: dla mnie dużo przyjemniejszy jest typeorm, syntax jest przyjemniejszy (normalnie masz @ManyToOne i inne takie takie, zamiast jakieś dziwne BelongsTo :P), dekoratory + generalnie profity płynące z typescriptu. Ale jest do de facto dość nowy ORM i czasami coś z dupy może nie działać, albo działa inaczej niż myślisz i ciężko ogarnąć co się dzieje. I dokumentacja mogła by być lepsza, często muszę przeglądać kod na gh, żeby
  • Odpowiedz
Arveit
Arveit
  • 0
@nehemiah: dzięki, spojrzę na to i przetestuję. Na co dzień jestem frontendowcem i zazwyczaj korzystam już z gotowego API, ale lubię zdobywać nową wiedzę :P

Może ja coś źle zaprojektowałem i nie powinno się robić takich zagnieżdżeń wielokrotnych? Bo w niektórych widokach, w których będe używał konkretnych obiektów nie będę potrzebował ich wszystkich składowych więc wydaje mi się bez sensu zwracanie ich z serwera i chciałbym mieć wpływ na to
  • Odpowiedz
grajlord
grajlord
  • 1
Mirki z #python - jak komunikować się z bazą danych w kilku wątkach, używając sqlachemy?
Mam obiekt klasy A odpowiadający rekordom w tabeli a, z relacją one-to-many do rekordów z tabeli b (obiekt klasy B). W głównym wątku aplikacji dokonuję operacji na obiekcie A, a w oddzielnym wątku (threading.Thread) tworzę nowe obiekty B, podając im jako argument obiekt A z głównego wątku (żeby zachować
grajlord
grajlord
  • 1
Siema mirki z Python, jaki jest preferowany/właściwy sposób budowania dziedzina dla klas ze sqlalchemy po klasach spoza tej biblioteki?
Chciałbym, aby klasa będąca modelem ORM ze sqlalchemy (powiedzmy User), dziedziczyła po klasie nie będącej takim modelem, powiedzmy Innaklasa z jakiegoś innego modułu. Zamysł jest taki, że metody z Innaklasa operują na danych które wyciągam z SQL używając klasy User. To pozwala na używanie klasy Innaklasa niezależnie od bazy danych.

Problem
grajlord
grajlord
  • 3
@grajlord: Ok, już wiem. Obiekty przy kwerendzie są inicjowane z pominięciem __init__. Trzeba dodać metodę z dekoratorem @sqlalchemy.orm.reconstructor, a w niej np. wywołać self.__init__() na jakichś własnych argumentach.
  • Odpowiedz
r.....s
r.....s
  • 1
#programowanie #dotnet #orm #entityframework
Mireczki mam taką sytuację, że posiadam użytkownika który posiada własne zamówienia (relacja nr.1) i może oglądać zamówienia swoich podopiecznych (relacja 2). Teraz chciałbym użytkownikowi wyświetlić dane z obu relacji w jednym widoku. Teraz jak do tego podejść. Pobrać z bazy danych obiekt użytkownika z dołączonymi obiema listami. (mam na myśli Include z ef, albo fetch z hibernate) i potem przemapować na jakiś view model czy może napisać jakieś query które ogarnie mi to po stronie serwera? Pierwsze podejście ma taki plus, że gdziekolwiek będę pobierał dane związane z użytkownikiem będę robił to używając jednego obiektu. Łatwo będzie to utrzymywać. Z drugiej strony jest mocny overhead jeżeli chodzi o pobierane dane i performance. Idea numer jeden wydaje mi się bardziej spójna z DDD bo mamy ten obiekt użytkownika który agreguje sobie jakieś zamówienia etc. Jest jeszcze problem z inicjalizacją obiektu użytkownika. Załóżmy, że chcielibyśmy wyciągnąć wszystkie zamówione rzeczy z wszystkich zamówień użytkownika i zsumować ilości poszczególnych przedmiotów. Po pierwsze musimy przy tworzeniu obiektu użytkownika musimy pamiętać żeby dołączyć całe drzewko encji po drugie wyciąganie tego wszystkiego i potem grupowanie po stronie servera trwałoby wieki.
Moje pytania do was:
1. Tworzycie osobne zapytania do poszczególnych widoków w aplikacjach? Jak nazywacie te obiekty które zwracają wam coś takie hmm można powiedzieć agregaty?

2. Co z logiką która występuje w zapytaniach. Tzn oprócz wyciągnięcia jakichś danych musicie dodatkowo coś wyliczyć. Trzymając się zamówień może to być np prawo do modyfikacji zamówienia w oparciu o jakieś zasady. Nie trzymamy tego w bazie danych i może się to przewijać przy wielu widokach. Przy wyborze opcji każdy widok ma swoje query będzie redundancja kodu.
siemanko
siemanko
  • 0
@kisi3l: Ok, dzięki za pomoc. Właśnie obecnie używam własnego generatora i używam UUID, ale boję się o konflikty. To co podesłałeś jest chyba tym czego szukam, tylko nie wiem jak z wydajnością.
  • Odpowiedz
uirapuru
uirapuru
  • 1
@gajowy_marucha: w doctrine również masz dziedziczenie, tam się dzieje to po abstrakcyjnym typie, który jest podstawą do zbudowania tabeli (nie po Eloquencie, a po "abstrakcyjnej" encji), a następnie dyskryminator doktrynowy sprawia (na podstawie dodatkowej kolumny w tabeli), że hydruje się obiekt odpowiedniej klasy, wedle zadanej wcześniej konfiguracji. Jedna klasa dziedzicząca może posiadać jedną relację, a druga inną. "Fizycznie" pojawią się w tabeli dwie kolumny, ale tylko jedna z nich będzie
  • Odpowiedz
KotoFan
KotoFan
  • 5
Nowa wersja Hibernate-orm 4.3.9.Final dzisiaj wyszła. Poniżej spam.

1. Znajdź błąd w #hibernate, smutnazaba.jpg
2. Google
3. Wejdź na Jirę hibernate i znajdź bug report z września ubiegłego roku, notokoniec.png
4. Status:CLOSED
siemanko
siemanko
  • 1
@Crisu: Ja mogę od siebie polecić ORMLite do mniejszych projektów. Przyjemne api oraz dobra dokumentacja.
Niezbędne np. na Androida, ale używam też na serwerze:)
  • Odpowiedz
a.....r
a.....r
  • 0
@Crisu: Jeśli ma być przenośność między różnymi bazami to można próbować z ORM - oraz gdy część zapytań musi być generowana dynamicznie. Inaczej proponuję użyć sql-a bezpośrednio.
  • Odpowiedz
echelon_
echelon_
  • 2
Pytanie architektoniczne a i może takie o właściwą implementację.

Mam ja klasę Rodzic, kolekcja @OneToMany dla Dzieci. Jednak chciałbym aby Rodzic nie miał standardowego gettera getDzieci() tylko sparametryzowany getDzieci(String imie).

Nie chcę pobierać wszystkich dzieci rodzica a potem filtrować bo nie dość, że już ORM zarzyna apkę to jeszcze chciałbym aby nikt przez pomyłkę po mnie nie pobrał wszystkich Dzieci danego rodzica. Oczywiście od biedy mogę zostawić oryginalny getter i oznaczyć go jako @

Powiązane tagi