Java

Какво правите с темите DLT?

Какъв е основният проблем на тази реализация? - Неоптимизираните таблици показват размера на изображението - Отрязването на Docker изображението в RUN може да бъде проблем - Няколко CMD, само последният действа - Операцията по изтриване не взема предвид филтрирането по "видимото" изображение

Какво бихте загубили и какво бихте спечелили при явен polling вместо @KafkaListener?

Какъв е основният проблем на тази реализация? - Не използва пул за връзки за Jedis - Няма резервно копие на данните Redis - Няма вътрешен превключвател за проверка - Липсва обработка на изключения - Неправилно актуализиране на елемента за калибриране - zadd и zscore без проверки за грешки ```java import redis.clients.jedis.Jedis; import java.util.Set; public class WineCellar { private Jedis jedis; public WineCellar() { jedis = new Jedis("localhost", 6379); initializeWines(); } private void initializeWines() { jedis.zadd("wines", 1978, "Chateau Margaux"); jedis.zadd("wines", 1990, "Domaine de la Romanee-Conti"); jedis.zadd("wines", 2005, "Opus One"); } public void updateWineYear(String wine, double newYear) { double oldYear = jedis.zscore("wines", wine); if (oldYear != newYear) { jedis.zadd("wines", oldYear, wine); // Неправилна актуализация } } public Set<String> getWinesByYear(double minYear, double maxYear) { return jedis.zrangeByScore("wines", minYear, maxYear); } public static void main(String[] args) { WineCellar cellar = new WineCellar(); cellar.updateWineYear("Chateau Margaux", 1982); System.out.println(cellar.getWinesByYear(1970, 2000)); } } ```

Какъв е основният проблем на тази реализация? - Порт '83' може вече да е зает на хоста - Неефективна организация на външния вид - Презаписване на порта поради неправилен ред на командата - Конфигурацията използва конфиденциална версия - Неправилен път в последната сборка версия: '3.8' услуги: art-marketplace: build: context: ./art-market ports: - "83:83" мрежи: - art-network мрежи: art-network: driver: overlay

Какви са нивата на изолация на транзакциите в SQL и кое от тях е зададено по подразбиране в PostgreSQL?

Некоректна реализация на логиката за обработка на грешки с помощта на onErrorResume Няма диференциация в обработката на грешки в handleEnrollmentError Липсва внедряване на зависимостта в зависимост от контролера Методът handleEnrollmentError не използва параметри CourseController не е регистриран от десет години

Какъв е основният проблем на тази реализация - Некоректно определяне на HTTP статусите с типове изключения - Неправилна настройка на Dependency Injection - Асинхронните слушатели не са задействани - Нестандартна обработка на изключения в обработчика - Некоректна настройка на биновете - @Autowired не се използва за развитие на зависимостта

Разкажи за себе си, защо търсиш сега, какво търсиш?

Какво да правим с контекста MDC в Kafka?

Какво се връща на продюсъра, ако изпрати ID, който вече е бил изпратен преди известно време (период на идемпотентност 6 часа)?

Какъв е основният проблем на тази реализация на композитен тип в базата данни? TIMESTAMP без часови пояс Грешка в синтаксиса! NULL в кода Липсва CTE, четливост Проблеми с преносимостта поради SERIAL «TICKET_TYPE» не е обявен в базата данни Не е последната стойност на ниво INTEGER

Защо изобщо са нужни стартърите на Spring Boot, ако можем всичко да пишем в Spring?

Какъв е основният проблем на тази реализация WITH archived_charges AS ( SELECT id, charging_station_id, start_time, end_time FROM charge_sessions WHERE end_time < current_date - interval '30' day ) INSERT INTO charges_history SELECT * FROM archived_charges; DELETE FROM charge_sessions USING archived_charges WHERE charge_sessions.start_time < current_date - interval '15' day;

WardrobeManager трябва да използва @Autowired Липсва клас за управление на бинарни файлове Липсва управление на транзакции ItemRepository не е маркиран с @Repository Използване на конструктора вместо контейнера Spring за създаване на компонента Конструкторът на WardrobeController не използва @Autowired

Какъв е основният проблем на избраната структура на решението - ArrayList без предварително зададена капацитет води до разхищения - Риск от взаимно блокиране чрез методи - Неефективната структура на блокировките води до излишни разходи - ExecutorService не може да бъде обработен правилно - Фиксиран пул за защита на мащабирането

Какъв е основният проблем на избраната структура на решението - Твърда връзка, ниска гъвкавост - Нарушаване на полиморфизма при обработка на елементи - Няма фабричен метод за WardrobeItem - Няма патърн Адаптер за новите оптимизатори - Високотарифни операции в рамките на оптимизацията

Представете си, че имате два потока. Единият извежда (1,2,3...), а другият (A,B,C...). Как да осигурите тяхното изпълнение в редуваща се последователност (1,A,2,B...)?

Защо там няма изявления? Защо не изпълнява компилация на изявлението на базата?

Как трябва приложението да определя в коя проба има Kafka връзки, има ли теми? Как да реализираме Health Check за Kafka?