acwartz

В Manifest v3 есть особенность service_worker, его скрипты должны лежать в корне папки, а не во вложенных папках по типу /public/js/background.js

Добрый день!
Во-первых, на основании ваших слов:

Есть сертификат(Certificate), у него может быть много тегов (Tag).
Предполагается что в таблице тегов может быть куча дубликатов по имени, т.е. 3 сертификата могут иметь один и тот же тег "Java" ну или как-то так.

Могу предположить, что связь OneToMany & ManyToOne не очень подходит.
Вот, смотрите: один сертификат может иметь несколько тегов, но при этом один тег может относится к разным сертификатам. Тут явно связь ManyToMany.
https://vladmihalcea.com/the-best-way-to-use-the-m...
https://www.baeldung.com/jpa-many-to-many
Соответственно, получится, что со стороны Certificate вы сможете получить список его тегов, а со тороны тега, можете получить список сертификатов, к которым он принадлежит.
А то у вас получается, что и со стороны тега и сертификата OneToMany связь, но при этом с обеих сторон используется List
При использовании ManyToMany будет создана новая таблица вида certificate_id | tag_id, где вы сможете хранить данные. И соответственно,

Как к entity присоединить список других entity и потом работать с ними и со списком?

Этот вопрос устранится само собой

КАЖДЫЕ 20 минут работы перед компом НА 20 минут ОТДЫХА.

На руках часы - каждые 30 минут вибрация, встаю, наливаю воду из кулера, делаю мини зарядку на глаз.

Итог: через каждые 30 минут 4к изображение снова появляется. Для спины - офисное кресло с жесткой спинкой(без качающегося механизма).

В обед после приема еды лучше не сидеть на попе, если есть возможность - погулять, постоять с коллегами, обсудить что нибудь.

Вечером после работы - спорт. Бег, плаванье, тренажерный зал = самое полезное что есть для программиста. Можно еще после плаванья пивка бахнуть, тоже тонус прибавляет.

PS: в 20 лет сделал операцию на глаза - было -6, стало 100%.
За 10 лет списком выше - со зрением и спиной пока что всё норм.

tries = 3 #число попыток ввести фигню
while tries: #пока не tires не 0 и не None
    print('>>> ', end='') #принти что-то
    command = input() # вводи текст
    if not command: # если command не обьявлен (ты ничего не ввел выше)
        continue 
        #начинай цикл заново не выполняя его нижнючасть
    if command in ('echo', 'cd', 'help'):  #если введенное равно любому элементу из списка
        break # досрочно прерви цикл
    print('Unknown command!') 
    tries -= 1 #уменьши tires на 1
else:
    print('Too many bad tries!') # выскочит когда ты три раза введешь фигню и tries  будер равен 0
    command = None

Если данных действительно много, то зависит от их структуры. Если структура есть(это много одинаковых записей), то, конечно, БД. Если это просто большой бинарь(аудио, видео, etc), то, конечно, файл во внешнем хранилище.
Bundle не подходит ни под каким соусом, это абстракция для короткого хранения состояния(например между открытиями экранов или смене конфигурации).

Укажи tabId вкладки, для которой нужно поменять иконку, т.е. новую иконку нужно дополнительно вручную для каждой уже открытой вкладки поставить. Без указания tabIdона поставится лишь для новых вкладок/после перезагрузки.

Git хранит историю изменений. Закоммитили вы в него тот код, который у вас есть сейчас, или нет - совершенно неважно. Главное - закоммитить в него тот код, который вы собрались изменять. Чтобы иметь его копию до изменений.
Пока вы пишете новый код - контроль версий не нужен. Как только понадобилось что-то в коде исправить - нужно сначала сделать коммит, чтобы, если исправление неудачно, не вспоминать, что именно и как именно было исправлено, а вернуться к предыдущей версии кода или наглядно сравнить ее с текущей.
К тому времени, когда код будет хоть что-то делать - у вас, скорее всего, уже не один десяток коммитов будет. Не бойтесь создать ненужный коммит - важны только те, которые понядобятся, а сколько будет прочих - совершенно некритично.
Обычная практика - сделал фичу, закоммитил код с комментарием "сделал эту фичу". Исправил баг - аналогично. Заодно еще и историю работы потом можно будет увидеть ;)

Мой собственный ответ после изучения темы и чтения иностранных коллег будет таким:

Технология была многообещающей и интересной на старте. Для ее поддержки гугл даже придумал отдельную спецификацию HTML Imports: https://w3c.github.io/webcomponents/spec/imports/i... (можете не ходить, там 404), что позволяло подключать однофайловые компоненты прямо в документ так:
<link rel="import" href="my-component.html">
Классно же да?

Но технология не приобрела популярности, возможно так как была слишком простой и понятной, а именно в это время на пик славы вышел npm, gulp и вот это всё. В моду входила непонятная магия, утрата контроля над кодом и всякие оптимизаторы позволявшие сделать для одного слайдера на главной страницы бандл в полтора, а иногда 2-3 Мб. кода, и всё это без всяких там jQuеry.
Ребята одумались и убрали спецификацию HTML Imports, предлагая разбивать компоненты на 3 отдельных файла - js, css и html с шаблоном. Причём js надо было подключать на странице, css тоже, а html должен был загружать по задумке создателей уже в само js. Такой подход позволял резко усложнить работу с web-components и сделать код снова неуправляемым, но было поздно - технология уже уступила позиции конкурентам.
Конечно это был сарказм, если кто-то не понял.

Жизнь в этой идее еще теплится, но теперь нам предлагается писать код в трех файлах или помещать его целиком в js, или использовать со специальными загрузчиками, что сопоставимо с использованием какого-нибудь фреймворка, того же Vue, дающее теме же усилиями гораздо большие возможности и смысл использовать веб-компоненты отпадает окончательно.

Короче технология по задумке хорошая, но на практике не применимая, поэтому широкого распространения и не получает.

Советую начать с книги «Изучаем Python» М.Лутц.