Қайталанатын

Iterable функциясын қайтаратын дерекқордан нысандарды жүктеу әдісі бар.

Мен қазір деректер базасынан нәтиже жүктеп жатырмын, одан объектілерді құрып, коллекцияны сол нысандармен толтырамын.

Әлбетте, мен бұл әдіс арқылы қанша деректерді жүктеуге болатындығын еске түсіремін, ал егер жаман істер орын алса.

Деректер базасынан деректердің дерекқорынан біртіндеп алудың орнына іске қосуды өзгерткім келеді, содан соң алынған кодтарды Iterable интерфейсі арқылы клиентке шығарады. Менің деректер базасының драйверлері өздерінің биттарын жасай алады, сондықтан менің ойымша, бұл мұны жасайтын Iterable пайдаланушы нұсқаулығы.

Бұл жақсы көзқарас ма? Бұл мені жұмыс уақытында немесе кітапханаларда қолдау көрсетілуі мүмкін нәрсе ретінде - ORM шешімдеріне қатысы жоқ.

2
Iterable ғана емес, Iterator енгізгіңіз келетін себеп бар ма? Итерацияны қайта бастау мүмкіндігін қосудың қажеті болмаса, кейінірек оңайырақ болады.
қосылды автор Joachim Sauer, көзі
Жақсы ой - ешқандай себеп жоқ
қосылды автор brabster, көзі

2 жауаптар

Мен өзім ойлайтын қарапайым шешім ResultSet айналасында жіңішке орау ретінде Iterator енгізу. Бұл бірнеше артықшылығы бар:

  • Жаңғыртылатын SQL мәлімдемелерін ұсынудың қажеті жоқ (мысалы, сұрыпталмаған нәтижелерді ағынмен жасауға болады)
  • Сенуге болмайды. қайталанатын оқу , ол қымбат болуы мүмкін
  • Егер сіздің JDBC драйвері жақсы болса, онда оның ағындық нәтиже мүмкіндіктерін пайдалануға болады (ескерту: кейбір JDBC драйверлері әрдайым толық нәтижеге қол жеткізе бастайды, оны қайта бастайсыз!)
  • Iterator ( Iterable.iterator() ) екі рет шақырылуы мүмкін, бұл оны күрделі етеді).
  • Бұрын қайтарылған деректерді «еске түсіру» емес, жадқа қатысты талап өте төмен деңгейде болуы мүмкін дегенді білдіреді

Ол сондай-ақ бірнеше кемшіліктері бар:

  • сіздің Iterator енгізуіңіз тиімді JDBC ресурсын байланыстыратындықтан, сыртқы ресурстарға айналады: ол «жабық» болуы керек, бұл оны пайдалануды қиындатады
  • егер Iterator ұзағырақ уақытқа созылса, онда де JDBC Connection қосуға мүмкіндік береді, ол басқа жерде қажет болуы мүмкін Iterator жасалғанша, оны бассейнге қайтара алмайсыз.)

Баламалы әдіс - List (немесе Collection ) іске асыру. Бұл пайдаланудың жақсы болуы мүмкін, бірақ салу үшін өте күрделі (дұрыс!). Сондай-ақ, егер жад шектеулері маңызды болса, бұрын қалпына келтірілген нысандарды тастауға арналған механизмді қосу қажет.

3
қосылды
Және балама әдіс (сіз айтқаныңыздай) офсетті есте сақтап, содан кейін қажетті орынға «айналдыру» үшін SELECT ... LIMIT M, N қолданыңыз. Әрине, ақпарат уақыттың ішінде өзгеруі мүмкін (басқа транзакция жаңа жолдар енгізілген немесе жойылған), бірақ бұл тәсіл JDBC байланысын жабуға мүмкіндік береді, бұл DB серверіне минутына көбірек мәмілелерді өңдеуге мүмкіндік береді.
қосылды автор dma_k, көзі

Мен Иоахимнің ұсынысымның бірінде ұсынылған тәсілін іске асырдым. ResultSet қаптамасының іске асырылуы жағдайында ResultSet destroy() әдісін қамтитын DestroyableIterator /code>. (Кейбір кітапханалар осы интерфейсті қамтамасыз етеді, бірақ 3 интерфейс анықтамасы үшін кітапханалық тәуелділікті енгізу нүктесін көрген жоқпын.)

SQLException с-мен next() және арқылы оларды тарату үшін DataAccessException hasNext() әдістері.

Ресурстарға қатысты мәселе жарамды болып табылады; Мен DestroyableIterator арқылы қолданба кодын бақылап жүрдім және тірі ResultSet торабын тым ұзақ уақыт ұстап қалудың әртүрлі уақытша механизмдері болды.

1
қосылды
Java 7 және одан жоғары деңгейде AutoClosable енгізуді және destroy() орнына close() функциясын қолдануды ұсынамын.
қосылды автор Joachim Sauer, көзі
Иә, бұл дегеніміз: DestroyableIterator жолын AutoClosable енгізіңіз (бұл кезде AutoClosableIterator ;-))
қосылды автор Joachim Sauer, көзі
Тек қана нәрсе, сіз автоматты түрде дананы пайдалана отырып AutoCloseable сынағыңыз келуі керек. Екі интерфейсті AutoCloseableIterator ретінде біріктіру мүмкін бе?
қосылды автор Adamski, көзі