Filtrowanie po wynikach metod

Witam, mam problem z rozwiązaniem problemu z filtracją po wynikach metod. Mam klase Car z której dziedziczyć będą różne klasy typu: Tir itd. Potrzebuje zrobić filtracje coś w stylu jak na otomoto że można podać np wartości długości auta od do, date produkcji od, albo tylko do oraz filtrowanie po wyniku metod averageSpeed oraz averageFuelCOnsumption, ale bez przypisywania ich jako pole. Próbowałem robić to criteria oraz QueryDSL ale nie wyszło. Z góry dziękuje za wszelkie porady. Pozdrawiam

@Setter
@NoArgsConstructor
@AllArgsConstructor
@Table(name = "APP_CAR")
@Entity
public abstract class Car {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private int id;
    private String type;
    private Double length;
    @CreatedBy
    private String createdBy;
    @CreatedDate
    private LocalDateTime createdAt;

    public abstract Double averageSpeed();
    public abstract Double averageFuelConsumption();
}

DopieroSieUcze napisał(a):

Witam, mam problem z rozwiązaniem problemu z filtracją po wynikach metod. Mam klase Car z której dziedziczyć będą różne klasy typu: Tir itd.

A muszą dziedziczyć?

Riddle napisał(a):

DopieroSieUcze napisał(a):

Witam, mam problem z rozwiązaniem problemu z filtracją po wynikach metod. Mam klase Car z której dziedziczyć będą różne klasy typu: Tir itd.

A muszą dziedziczyć?

Tak muszą. W tym mam problem żeby filtrując w bazie danych zwracało obiekty nie tylko samego Car ale również klas dziedziczących

@DopieroSieUcze:

Tir dziedziczący po Car to mętne bardzo.

Dziedziczenie odnośnie encji JPA - choć możliwe - to bardzo subtelny i bogaty w profesjonalne zagadnienia temat (sorry, ale nie przeskoczysz tego "z marszu")
Mętniejsze jeszcze bardziej.

Właściwie można powiedzieć, że upada całe myślenie o dziedziczeniu, jakie by było w ujęciu czysto obiektowym. *)
Dylemat relacyjno-obiektowy głęboko zmienia ... bardzo dużo się zmienia.

*) a i w ujęciu czysto obiektowym współczesnie o WIELE, WIELE MNIEJ się kierujemy w stronę dzedziczenia, czyli relacji obiektowej "is", na rzecz np relacji obiektowej "has", np Car has Category

ZrobieDobrze napisał(a):

*) a i w ujęciu czysto obiektowym współczesnie o WIELE, WIELE MNIEJ się kierujemy w stronę dzedziczenia, czyli relacji obiektowej "is", na rzecz np relacji obiektowej "has", np Car has Category

Ale Ty wiesz że te wszystkie relacje "is" i "has", to są wymyślone i nie mają specjalnego pokrycia w programowaniu, nie? :>

DopieroSieUcze napisał(a):

problemu z filtracją po wynikach metod.

Z biliotek / frameworków obiektowo-relacyjnych jakich dotykałem, chyba tylko jeden (closed soursowy) ma filtrację "jakby" po wynikach metod, przy czym jak refren twórca daje zastrzeżenia, że jest to wolne, bo filtracja zachodzi PO POBRANIU wszystkich obiektów do RAM, a nie na poziomie bazy danych

Riddle napisał(a):

ZrobieDobrze napisał(a):

*) a i w ujęciu czysto obiektowym współczesnie o WIELE, WIELE MNIEJ się kierujemy w stronę dzedziczenia, czyli relacji obiektowej "is", na rzecz np relacji obiektowej "has", np Car has Category

Ale Ty wiesz że te wszystkie relacje "is" i "has", to są wymyślone i nie mają specjalnego pokrycia w programowaniu, nie? :>

Bądż łaskaw zielonemu to wytłumaczyć ładnie i nie psując systematyki. Jak ma razie tylko bełtasz białko

ZrobieDobrze napisał(a):

Riddle napisał(a):

ZrobieDobrze napisał(a):

*) a i w ujęciu czysto obiektowym współczesnie o WIELE, WIELE MNIEJ się kierujemy w stronę dzedziczenia, czyli relacji obiektowej "is", na rzecz np relacji obiektowej "has", np Car has Category

Ale Ty wiesz że te wszystkie relacje "is" i "has", to są wymyślone i nie mają specjalnego pokrycia w programowaniu, nie? :>

Bądż łaskaw zielonemu to wytłumaczyć ładnie i nie psując systematyki. Jak ma razie tylko bełtasz białko

Twój opis tutaj, ładnie to wyjaśnił:

ZrobieDobrze napisał(a):

@DopieroSieUcze:

Tir dziedziczący po Car to mętne bardzo.

Dziedziczenie odnośnie encji JPA - choć możliwe - to bardzo subtelny i bogaty w profesjonalne zagadnienia temat (sorry, ale nie przeskoczysz tego "z marszu")
Mętniejsze jeszcze bardziej.

Właściwie można powiedzieć, że upada całe myślenie o dziedziczeniu, jakie by było w ujęciu czysto obiektowym. *)
Dylemat relacyjno-obiektowy głęboko zmienia ... bardzo dużo się zmienia.

Więc nie ma sensu powielać.

Tylko ten dopisek: a i w ujęciu czysto obiektowym współczesnie o WIELE, WIELE MNIEJ się kierujemy w stronę dzedziczenia, czyli relacji obiektowej "is", na rzecz np relacji obiektowej "has", np Car has Category, to to już jest wymyślone i nie ma odniesienia w programowaniu.

To może wytłumaczysz to lepiej? :P — cerrato 3 minuty temu

ZrobieDobrze napisał(a):

Właściwie można powiedzieć, że upada całe myślenie o dziedziczeniu, jakie by było w ujęciu czysto obiektowym. *)
Dylemat relacyjno-obiektowy głęboko zmienia ... bardzo dużo się zmienia.

Wiec zajmijmy się najpierw dziedziczeniem jako zagadnieniem w celu filtrowania długotrwałych (perzystentnych) danych.
Dziedziczenie w programie (bez bazy) prezentuje użytkowo pewną hierarchię klas, która jest ważna tak długo, jak długo program jest aktywny.
Być może następne uruchomienie programu będzie w wersji 1.01, gdzie hierarchia klas dozna zmian. Ale to nie ma znaczenia, bo to wywołanie nie dotyczy przeszłośći, a teraźniejszości

Z danymi perzystentnymi jest inaczej. Drugie (kolejne) uruchomienie obcuje z zapisanymi struktorami danych z innej wersji. (Piszę ogólnie, nie wnikam w realizację JPA)
To pierwszy problem.
Wiele rzeczy moze się stać. Może jakaś klasa wypaść albo być przeniesiona. Może w bazie zabetonujemy chorą hierarchię wer 1.00.

Może staniemy wobec faktu rozwidlenia dla klientów.
Jeden z nabywców naszego programu handluje samobieżnymi maszynami budowlami ONLY, 90% hierarchii go nie obchodzi, jest nieużyteczne, ALE koniecznie potzreuje na koparki, spychy, kanalizacyjne itd ..
Inny luksusowymi osobówkami, i chce dzielić ze swoimi subtenościami

C.D. I rozwidlenie dla klientów jest idealnym "pociskiem podkalibrtowym" w dziedziczenie, bum, błysk i dym, wszystko fruwa i nic nie zostaje- a jest pięknie implementowalne jako "has Category"
(referencja JPA)

Jednak myśle że rozumiesz że chodzi o getArea i getPerimeter — DopieroSieUcze 49 minut temu

Zamiast kopać z koniem, może przemyślisz projekt.

Np ODMIENNIE niż w czystym programowaniu obiektowym, MOŻEMY przechowywać obliczone liczby (choć niby pozornie wynikają z minimalnych zapisanych)

@Entity
class Figure {
    Shape kind;
    double x,y;
    double area;
    
    Figure(double x0, double y0)
    {
     x = 
     y = 
      area = kind.computeArea( this )    // koło x*x*3.14/4 zby wczesne wywołanie, daje warningi Javy
    }
}

Dla takiej encji, baza (a nie klient) może przeszukiwać po polu area, a hipotetycznie nawet możemy mieć na tym indeks

Ważne jest to, że gdy schodzimy w okolice baz danych, o obiektach nie myślimy tak samo jak w sytuacjach czystych. To se ne vrati, pane Havraneki
Wiele rzeczy się zmienia przy posiadaniu bazy, ale na początku nie masz możliwosci tego doświadczyć własnymi pazuram

W sytucjach biznesowych przechowujemy netto, brutto, choć pozornie niepotrzebnie (bo pinokio zmieni VAT)

ZrobieDobrze napisał(a):

W sytucjach biznesowych przechowujemy netto, brutto, choć pozornie niepotrzebnie (bo pinokio zmieni VAT)

Właśnie jak najbardziej potrzebne (bo pinokio zmieni VAT).

• Zrobiono fakturę w zeszłym roku, pinokio zmienił VAT, ale ta faktura ma zostać taka jak była bo ona już zaraportowana fiskusowi.
• To nie nasza faktura wyliczenie VAT to ich sprawa, możemy odliczyć dokładnie tyle VAT'u ile oni naliczyli, zaś oni VAT liczą od: - brutto, netto, ceny, d**y
• Możemy VAT liczyć od netto po przemnożeniu cena*ilość, od netto z ceny po czym mnożymy razy ilość, od brutto

Czyli każdy orze jak może.

_13th_Dragon napisał(a):

• Zrobiono fakturę w zeszłym roku, pinokio zmienił VAT, ale ta faktura ma zostać taka jak była bo ona już zaraportowana fiskusowi.

Miałam takiego przełożonego co tego nie rozumiał i gorzej kłócił się ze mnąże różne takie rzeczy maja byc licozone po stronie frontu i nie sprawdzane na backendzie przed zapisem