[scala]: tworzenie klasy przez refleksję

A jak chcesz ustawiać pola w tym DTO? Po nazwie?

Shalom napisał(a):

A jak chcesz ustawiać pola w tym DTO? Po nazwie?

tak, to będzie kolejny krok do rozkminienia

Nie bardzo rozumiem sens. Gdzieś, np. przy wywołaniu, i tak musisz powiedzieć co to będzie za typ, więc czemu zwyczajnie nie wysyłać referencji do konstruktora do tej twojej metody, w sensie jako argumentu jakiegoś CountriesDto::new

Niezbyt szczaiłem...

Shalom napisał(a):

Gdzieś, np. przy wywołaniu,

przy wywołaniu czego?

Shalom napisał(a):

więc czemu zwyczajnie nie wysyłać referencji do konstruktora

której referencji do którego konstruktora?

Shalom napisał(a):

do tej twojej metody

której metody?

Co chcesz osiągnąć? Po co chcesz używać refleksji

CountriesDto.getClass zwraca klasę singletona (czyli to mniej więcej odpowiednik Javowego SingletonCośtam.getInstance().getClass()). Odpowiednikiem Javowego Klasa.class jest Scalowe classOf[Klasa].

Taki kod działa w Scali 2.13:

case class CountriesDto(isoCode: String, name: String, languagesIsoCodes: String, isEnabled: Boolean)

Class.forName(classOf[CountriesDto].getName).getDeclaredConstructors()(0).newInstance("aa", "aa", "aa", true)

Scala 2.12 wymaga takiego kodu:

case class CountriesDto(isoCode: String, name: String, languagesIsoCodes: String, isEnabled: Boolean)

Class.forName(classOf[CountriesDto].getName).getDeclaredConstructors()(0).newInstance("aa", "aa", "aa", Boolean.box(true))

Po co w ogóle używasz refleksji? W Scali refleksja to ogólnie antywzorzec, bo jest mnóstwo fajnych mechanizmów w języku.

Aktualizacja:
aaa, dobra, widzę:

Używam refleksji, bo chcę zrobić automatyczne inicjowanie dowolnego Dto mając java.sql.ResultSet. Każde Dto będzie miało nazwy zmiennych takie same jak nazwy kolumn ResultSet.

Przecież do tego są biblioteki jak Slick, Quill, etc

Użyć chcę refleksji, żeby nie musieć dla każdego Dto pisać mappera np.:

dla ProvidersHostsDto:

  override def findAll: Seq[ProvidersHostsDto] = {
    def mapper(rs: ResultSet) = ProvidersHostsDto(rs.getInt(1), rs.getString(2), rs.getString(3), rs.getBoolean(4))
    postgresIOEngine.selectAll(mapper)
  }

dla TagsDto:

  override def findAll: Seq[TagsDto] = {
    def mapper(rs: ResultSet) = TagsDto(rs.getInt(1), rs.getString(2), rs.getBoolean(3))
    postgresIOEngine.selectAll(mapper)
  }

dla RankingDto:

 override def findAll: Seq[RankingDto] = {
    def mapper(rs: ResultSet) = {
      var count = Option(rs.getLong(7))
      if (rs.wasNull()) {
        count = Option.empty[Long]
      }
      RankingDto(
        rs.getTimestamp(1).toLocalDateTime,
        rs.getInt(2),
        rs.getString(3),
        rs.getInt(4),
        rs.getInt(5),
        rs.getTimestamp(6).toLocalDateTime,
        count
      )
    }
    postgresIOEngine.selectAll(mapper)
  }

gdzie ten silnik postgresIOEngine wygląda tak:

class PostgresIOEngine[A](conn_str: String, table: String) {

  def selectAll(mapper: ResultSet => A): Seq[A] = {
    val sql = s"SELECT * FROM $table"
    select(sql, mapper)
  }

  def select(sql: String, mapper: ResultSet => A): Seq[A] = {
    var rows = ListBuffer[A]()
    classOf[org.postgresql.Driver]
    val conn = DriverManager.getConnection(conn_str)
    try {
      val stmt = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY)
      val rs = stmt.executeQuery(sql)
      while (rs.next) {
        rows += mapper(rs)
      }
    }
    finally {
      conn.close()
    }
    rows
  }

// ...

}

Wtedy zamiast mieć na każdą tabele po jednym Dao miałbym jedno Dao do wszystkiego

A tak w ogóle to dlaczego piszesz w Scali jakby to była Java? Myślałem, że programowanie funkcyjne w Scali wyglada inaczej, jest inny ekosystem i w ogóle :)

Do osiągnięcia tego nie potrzebujesz żadnej refleksji. Owszem, będziesz musiał napisać funkcję ResultSet => A gdzie A to DTO, ale takie funkcje chcesz napisać i mieć kontrole nad nimi (pracując na tak "niskim" poziomie jak ResultSet).

Ogólnie, swoje rozwiązanie możesz rozbudować żebyś nie musiał dla każdego DTO pisać funkcji findAll:

trait Extractor[A] {
    def extract(rs: ResultSet): A
}

object Extractor {
    def apply[A](implicit ext: Extractor[A]): Extractor[A] = ext

    implicit val countryExtractor: Extractor[CountryDto] = (rs: ResultSet) => ???
}

def selectAll[A: Extractor](): Seq[A] = {
    val sql = s"SELECT * FROM $table"
    select(sql, Extractor[A].extract)
}

def findAll[A: Extractor](): Seq[A] = postgresIOEngine.selectAll()

Oczywiście nie jest to jedyne rozwiązanie (najlepszym to będzie użycie biblioteki która to ogarnie za Ciebie) ani też optymalne. Nie mniej - używaj tego co Ci oferuje Scala. Rzadko kiedy będziesz musiał używać refleksji (o ile w ogóle).

Czego nie wymyślisz, to zapewne wszystko będzie lepsze niż refleksja i sobie podziękujesz w przyszłości za to.

@Julian_:
Co się stanie jak zrobisz joina albo będziesz chciał wyciągnąć tylko część kolumn? Machniesz nowe DTOsy? Co jak będziesz chciał wstawić wiersz w tabeli z kluczem obcym? Moim zdaniem robisz abstrakcje w złym miejscu i złymi mechanizmami. Ręczne robienie mapperków mi nie przeszkadza, bo przynajmniej nie muszę się martwić jak pożenić magię refleksji z wspomnianymi joinami, kluczami obcymi i pomijaniem kolumn z tabeli. Wolę możliwość kompozycji zapytań, tzn wydzielenie wspólnych części zapytań jako osobnych wartości, np: https://getquill.io/#quotation-introduction

Ten wątek jest kontynuacją poczynań z tego: https://4programmers.net/Forum/Java/340621-scala_czytanie_tabel?p=1681997#id1681997

Wygląda na to, że wybrałeś sposób bez dodatkowych mapujących bibliotek (tak jak wspominałem w jednym z postów).

Też bym tą ścieżkę wybrał gdybym nie miał złożonych danych. Zwrócie uwagę, że Julian parzy w bazie CSVki - prawdopodobnie będą to proste zapytania, prawdopodobnie nic złożonego co wymagałoby od razu stosowania mappera. Mapper w tym przypadku to przerost formy nad treścią (to tak jakbyście chcieli wybrać zapach do łazienki podczas gdy Julian załatwia potrzebę w lesie - rozumiecie, totalnie bez sensu wątek). Podobnie jest ze stosowaniem bazy, ale cóż jak wybrał tak wybrał, być może to było mniejsze zło. Gdy mówicie mu by przeszedł na mapper, to tym samym szkoda mi Juliana, bo pewnie skończy zarywając noce.

Julian, wracając do Twojego problemu. Zobacz to tak: masz mało danych, prawdopodobnie wszystkie zapytania wyliczysz na obu dłoniach - po co tak komplikujesz? Naprawdę chcesz robić od podstaw ultra-ogólny-mapper?

Pff..

1. Po pierwsze nie pisz silnika zapytań do PG, mam ciary na plecach gdy to widzę.
2. Po drugie napisz nawet i z 10-20 maperów, w czym one Cię bolą? Masz język statycznie typowany, mniej więcej o to chodzi by dane dynamiczne jakie dostaniesz z SQL zmapować na strukturę jaką operujesz w kodzie. To musisz zrobić mniej więcej tak samo jak potrzeby fizjologiczne.
3. Im mniej refleksji i tego typu gównien zastosujesz tym spokojniej będzięsz spał. W przeciwnym razie pisz ten projekt w pythonie, bo w scali właśnie powstaje Ci równie dynamiczny język :D