Eigene IDs im Interface vergeben

[fb4thxUall]

Lieber Jure,
hallo zusammen,

ich schlage auch hier nochmal öffentlich diskutierbar folgendes neues Feature vor: Man sollte beim Neuanlegen eines Bib-Users auch eine eigene ID im grafischen Interface vergeben können. Das hat zum Beispiel für Schulen den Vorteil, dass man bestehende IDs aus bereits existierenden Systemen (Schulverwaltungssoftware, Mensasystem usw.) auch in openlibry verwenden kann. Das wiederum ermöglicht es, dass man nicht alle persönlichen Daten für alle Bib-Betreuer (bei uns sind das auch ältere SchülerInnen) sichtbar in OpenLibry hinterlegen muss. Es genügt zum Beispiel der Name und die (fremde) ID. Sollte dann Bedarf bestehen, die Daten zu erfahren, kann die verantwortliche Lehrkraft im Schulsystem unter der ID nachschlagen.
Das erspart einige Datenschutzprobleme.

Bei uns ist diese ID auch auf dem Schülerausweis abgedruckt, sodass dieser automatisch mit als Bib-Ausweis fungieren kann.

Gleichzeitig hätte das Feature keine Einschänkungen für andere Use-Cases, da ja auch immer noch eine auto-generierte ID optional genutzt werden kann. Auch ist der Implementationsaufwand mMn überschaubar.

Für meine Schule wäre das der letzte verbleibende entscheidende Game-Changer, um openlibry einzuführen.

Ganz herzlichen Dank insbesondere an Jure für die tolle Arbeit.

Viele Grüße

[jzakotnik]

@fb4thxUall Danke für das Feedback! Glaube der einfachste Weg wäre bei der Anlage des Users die ID abzufragen - danach ist sie aber fix, sonst wird es zu kompliziert z.B. die Leihen upzudaten. Sollte in den nächsten Tagen im Main Branch sein 💯 .

[fb4thxUall]

Ja natürlich, die ID bleibt anschließend ein Schülerleben lang. Anders wäre schwierig. Sehr sehr cool. Dankeschön.

[jzakotnik]

Almost there, nur noch ein wenig Fehlerhandling falls die ID schon existiert.. Ansonsten spuckt die automatische ID die nächste aus, welche die Datenbank vergeben würde, also @fb4thxUall falls ihr die IDs hintereinander eingebt, dann müsstet ihr theoretisch gar nicht viel manuell eingeben?

[fb4thxUall]

Das klingt praktisch, ist bei uns konkret aber tatsächlich nicht der Fall. Da sind große Lücken. Aber eine gute Idee, hilft anderen vielleicht.

[jzakotnik]

@fb4thxUall die erste Version für manuelle IDs ist jetzt im main branch, magst es mal ausprobieren?

[jzakotnik]

Noch eine kleine Randbemerkung: Ich glaube, ein kurzer Leitfaden explizit für Nicht-Techies an Schulen mit Leitfaden von A-Z von Installation bis Instandhaltung wäre super praktisch. Ich werde damit mal anfangen und das zur Verfügung stellen, sobald hier alles dauerhaft funktionierend läuft. Ich hoffe, das ist in deinem Sinne?

Na klar, je mehr Leute sich beteiligen, desto besser - das wäre ja der Vorteil von Open Source gegenüber kommerziellen Paketen..

[fb4thxUall]

Zum Fehler: Hier der komplette Log. Als Zusatzinfo: Ich habe ohne eingetragene Klasse auf Speichern geklickt.

big@big-HP-250-G6-Notebook-PC:~/openlibry$ docker compose up WARN[0000] /home/big/openlibry/docker-compose.yml: versionis obsolete [+] Running 1/0 ✔ Container openlibry Created 0.0s Attaching to openlibry openlibry | openlibry | > [[email protected]](mailto:[email protected]) start openlibry | > PORT=3000 next start openlibry | openlibry | ▲ Next.js 14.2.4 openlibry | - Local: http://localhost:3000/ openlibry | openlibry | ✓ Starting... openlibry | Server startup openlibry | ✓ Ready in 756ms openlibry | Server startup openlibry | ERROR in getAllUsers: PrismaClientKnownRequestError: openlibry | Invalidprisma.user.findMany()invocation: openlibry | openlibry | openlibry | Inconsistent column data: Conversion failed: Value 18974892374 does not fit in an INT column, try migrating the 'id' column type to BIGINT openlibry | at In.handleRequestError (/app/node_modules/@prisma/client/runtime/library.js:122:6877) openlibry | at In.handleAndLogRequestError (/app/node_modules/@prisma/client/runtime/library.js:122:6211) openlibry | at In.request (/app/node_modules/@prisma/client/runtime/library.js:122:5919) openlibry | at async l (/app/node_modules/@prisma/client/runtime/library.js:127:11167) openlibry | at async a (/app/.next/server/pages/user.js:1:11253) openlibry | at async eZ (/app/.next/server/pages/user.js:1:8232) openlibry | at async e3 (/app/node_modules/next/dist/compiled/next-server/pages.runtime.prod.js:31:594) openlibry | at async doRender (/app/node_modules/next/dist/server/base-server.js:1425:30) openlibry | at async cacheEntry.responseCache.get.routeKind (/app/node_modules/next/dist/server/base-server.js:1599:28) openlibry | at async NextNodeServer.renderToResponseWithComponentsImpl (/app/node_modules/next/dist/server/base-server.js:1507:28) { openlibry | code: 'P2023', openlibry | clientVersion: '5.15.1', openlibry | meta: { openlibry | modelName: 'User', openlibry | message: "Conversion failed: Value 18974892374 does not fit in an INT column, try migrating the 'id' column type to BIGINT" openlibry | } openlibry | } openlibry | ⨯ PrismaClientKnownRequestError: openlibry | Invalidprisma.user.findMany()invocation: openlibry | openlibry | openlibry | Inconsistent column data: Conversion failed: Value 18974892374 does not fit in an INT column, try migrating the 'id' column type to BIGINT openlibry | at In.handleRequestError (/app/node_modules/@prisma/client/runtime/library.js:122:6877) openlibry | at In.handleAndLogRequestError (/app/node_modules/@prisma/client/runtime/library.js:122:6211) openlibry | at In.request (/app/node_modules/@prisma/client/runtime/library.js:122:5919) openlibry | at async l (/app/node_modules/@prisma/client/runtime/library.js:127:11167) openlibry | at async a (/app/.next/server/pages/user.js:1:11253) openlibry | at async eZ (/app/.next/server/pages/user.js:1:8232) openlibry | at async e3 (/app/node_modules/next/dist/compiled/next-server/pages.runtime.prod.js:31:594) openlibry | at async doRender (/app/node_modules/next/dist/server/base-server.js:1425:30) openlibry | at async cacheEntry.responseCache.get.routeKind (/app/node_modules/next/dist/server/base-server.js:1599:28) openlibry | at async NextNodeServer.renderToResponseWithComponentsImpl (/app/node_modules/next/dist/server/base-server.js:1507:28) { openlibry | code: 'P2023', openlibry | clientVersion: '5.15.1', openlibry | meta: { openlibry | modelName: 'User', openlibry | message: "Conversion failed: Value 18974892374 does not fit in an INT column, try migrating the 'id' column type to BIGINT" openlibry | } openlibry | } openlibry | ERROR in getAllUsers: PrismaClientKnownRequestError: openlibry | Invalidprisma.user.findMany()invocation: openlibry | openlibry | openlibry | Inconsistent column data: Conversion failed: Value 18974892374 does not fit in an INT column, try migrating the 'id' column type to BIGINT openlibry | at In.handleRequestError (/app/node_modules/@prisma/client/runtime/library.js:122:6877) openlibry | at In.handleAndLogRequestError (/app/node_modules/@prisma/client/runtime/library.js:122:6211) openlibry | at In.request (/app/node_modules/@prisma/client/runtime/library.js:122:5919) openlibry | at async l (/app/node_modules/@prisma/client/runtime/library.js:127:11167) openlibry | at async a (/app/.next/server/pages/user.js:1:11253) openlibry | at async eZ (/app/.next/server/pages/user.js:1:8232) openlibry | at async e3 (/app/node_modules/next/dist/compiled/next-server/pages.runtime.prod.js:31:594) openlibry | at async doRender (/app/node_modules/next/dist/server/base-server.js:1425:30) openlibry | at async cacheEntry.responseCache.get.routeKind (/app/node_modules/next/dist/server/base-server.js:1599:28) openlibry | at async NextNodeServer.renderToResponseWithComponentsImpl (/app/node_modules/next/dist/server/base-server.js:1507:28) { openlibry | code: 'P2023', openlibry | clientVersion: '5.15.1', openlibry | meta: { openlibry | modelName: 'User', openlibry | message: "Conversion failed: Value 18974892374 does not fit in an INT column, try migrating the 'id' column type to BIGINT" openlibry | } openlibry | } openlibry | ⨯ PrismaClientKnownRequestError: openlibry | Invalidprisma.user.findMany()` invocation:
openlibry |
openlibry |
openlibry | Inconsistent column data: Conversion failed: Value 18974892374 does not fit in an INT column, try migrating the 'id' column type to BIGINT
openlibry | at In.handleRequestError (/app/node_modules/@prisma/client/runtime/library.js:122:6877)
openlibry | at In.handleAndLogRequestError (/app/node_modules/@prisma/client/runtime/library.js:122:6211)
openlibry | at In.request (/app/node_modules/@prisma/client/runtime/library.js:122:5919)
openlibry | at async l (/app/node_modules/@prisma/client/runtime/library.js:127:11167)
openlibry | at async a (/app/.next/server/pages/user.js:1:11253)
openlibry | at async eZ (/app/.next/server/pages/user.js:1:8232)
openlibry | at async e3 (/app/node_modules/next/dist/compiled/next-server/pages.runtime.prod.js:31:594)
openlibry | at async doRender (/app/node_modules/next/dist/server/base-server.js:1425:30)
openlibry | at async cacheEntry.responseCache.get.routeKind (/app/node_modules/next/dist/server/base-server.js:1599:28)
openlibry | at async NextNodeServer.renderToResponseWithComponentsImpl (/app/node_modules/next/dist/server/base-server.js:1507:28) {
openlibry | code: 'P2023',
openlibry | clientVersion: '5.15.1',
openlibry | meta: {
openlibry | modelName: 'User',
openlibry | message: "Conversion failed: Value 18974892374 does not fit in an INT column, try migrating the 'id' column type to BIGINT"
openlibry | }
openlibry | }

`

[jzakotnik]

Ok der Fehler ist eindeutig und nachstellbar, danke, Issue #102 . Das ist wirklich tricky, weil BigInt von next.js nicht serialisiert werden kann, da muss man sich was überlegen 👍
Übrigens, falls es eine Liste der User gibt, das wäre via API viel einfacher das initial automatisiert anzulegen. Ich denke ChatGPT könnte die Liste in eine entsprechende Sequenz von curl Kommandos umwandeln.

[fb4thxUall]

Hi,

zumindest für uns ist kein BigInt nötig, konnte das jetzt final abklären. Normales Int genügt. Dann würde es zumindest für mich genügen, es bei der aktuellen Version zu belassen. Würde nur den potentiellen Fehler im Code im Sinne der Robustheit abfangen, sodass bei zu große Zahlen nicht gleich alles komplett abschmiert.

Weitere Detailtests mache ich in Kürze.

Danke und LG

[jzakotnik]

Danke, ja ich war schon ein wenig ratlos. BigInt ist in node schon recht störrisch, z.B. kann man es nicht einfach so serialisieren und vom Server in den Browser übergeben. Mein Vorschlag wäre eher in der Eingabe ein Limit einzubauen.

[fb4thxUall]

Alles erledigt