-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicate event ids (36C3, GPN22) #63
Comments
Das passiert immer wenn wir uns bei der Anzahl der Talks pro Quelle verschätzen, das Skript warnt zur Runtime auch das das passiert:
Im Nachhinein lässt sich das leider nur noch von Hand korrigieren, ich empfehle jedem sich besser auf die GUIDs zu verlassen. Soll ich in dem Fall manuell die ID erhöhen oder ist das egal? |
Kann man den Offset generell größer wählen, so dass es nicht mehr dazu kommt? Eine Korrektur im Generierungsskript sollte umgesetzt werden, eine Korrektur in den Ausgabedateien wäre nett. Zum Hintergrund: In der Android-App führt die selbe ID zu falsch detektieren Fahrplan-Änderungen, die den Nutzern bei jedem Refresh angezeigt werden. Die GUID schaue ich mir an. Danke. |
zur Kenntnis @ideadapt! |
@johnjohndoe Soll man das für die Daten vom 36C3 noch korrigieren, würde halt auch wiederum zu fehlerhafen updates führen... Konntest du den schon auf die GUID umstellen? |
@saerdnaer Leider hatte ich noch keine Zeit, mich mit einer Umstellung auf GUID zu beschäftigen. Wenn ich richtig verstehe, würde es bei den 36C3-Daten nur noch 1x zu einem fehlerhaften Update kommen, richtig? |
Wenn ich mir den Aufwand machen würde ja... Also ich könnte halt einmal von Hand ein json bauen das keine Konflikte hat und das dann auch in nen XML umwandeln, oder ich würde die offsets nochmal komplett neu definieren – dann ändern sich aber mehr als nur die von Konflikten betroffenen Events. Fragt sich halt ob sich der Aufwand für ne vergangene Konferenz wirklich lohnt... |
Für mich stellt sich maßgeblich die Frage, ob sich der Fehler zukünftig vermeiden lässt, auch ohne dass EventFahrplan zeitnah auf GUIDs umsteigt? Den Aufwand für den 36C3 musst du nicht treiben. |
Da müssen wir einfach schauen das wir beim nächsten mal beim id-offset Parameter größere Lücken einbauen, so das sich das nicht mehr überschneidet... Besseres Monitoring bzw. Alerting im Fehlerfall wäre sicher auch nicht verkehrt. Lines 39 to 54 in db5fde7
|
z.K. Ich habe mal einen Issue für die Migration angelegt. Siehe EventFahrplan/EventFahrplan#319. |
Bei meiner Arbeit/Tests an der Umstellung habe ich gemerkt, dass die
Dabei handelt es sich um Workshops, die zum gleichen Thema stattfinden - aber zu unterschiedlichen Uhrzeiten. Ich vermute, die Berechnung der <event guid="81f5f0c4-3d35-522c-8f1c-c8825b92f00a" id="367">
<logo/>
<date>2019-12-27T16:10:00+01:00</date>
<start>16:10</start>
<duration>02:00</duration>
<room>OIO Workshop Dome</room>
<slug>SRMX8W</slug>
<url>https://talks.oio.social/36c3-oio/talk/SRMX8W/</url>
<title>Beginners Workshop: How to Hack your Web Application</title>
<subtitle/>
<track>Security</track>
<type>Workshop 1 hour</type>
<language>en</language>
<abstract>Did you ever want to know how hacking works? This beginners workshops gives an introduction into vulnerabilities, application pen testing and the security of web applications. Only if you know how hackers attack your application, you will be able to defend yourself. Nearly all companies use web applications nowadays. Any vulnerability in those applications may be an invitation for hackers to attack it. This workshop will give you insights on those things that you should never neglect when programming your application. From Techie to Techie!
Requirements: programming experience & laptop needed, security knowledge is not necessary</abstract>
<description>Find the Workshop slides here: https://drive.google.com/file/d/1sfCH6D2ZCzBhbPNx6GWHgBEIFRYEser6/view?usp=sharing</description>
<recording>
<license/>
<optout>false</optout>
</recording>
<persons>
<person id="136">Janosch Maier</person>
</persons>
<links/>
<attachments/>
<answers/>
</event> ... <event guid="81f5f0c4-3d35-522c-8f1c-c8825b92f00a" id="367">
<logo/>
<date>2019-12-27T17:15:00+01:00</date>
<start>17:15</start>
<duration>01:00</duration>
<room>OIO Workshop Dome</room>
<slug>SRMX8W</slug>
<url>https://talks.oio.social/36c3-oio/talk/SRMX8W/</url>
<title>Beginners Workshop: How to Hack your Web Application</title>
<subtitle/>
<track>Security</track>
<type>Workshop 1 hour</type>
<language>en</language>
<abstract>Did you ever want to know how hacking works? This beginners workshops gives an introduction into vulnerabilities, application pen testing and the security of web applications. Only if you know how hackers attack your application, you will be able to defend yourself. Nearly all companies use web applications nowadays. Any vulnerability in those applications may be an invitation for hackers to attack it. This workshop will give you insights on those things that you should never neglect when programming your application. From Techie to Techie!
Requirements: programming experience & laptop needed, security knowledge is not necessary</abstract>
<description>Find the Workshop slides here: https://drive.google.com/file/d/1sfCH6D2ZCzBhbPNx6GWHgBEIFRYEser6/view?usp=sharing</description>
<recording>
<license/>
<optout>false</optout>
</recording>
<persons>
<person id="136">Janosch Maier</person>
</persons>
<links/>
<attachments/>
<answers/>
</event> Ich möchte vorschlagen, dass das Skript, das die |
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
!!! ATTENTION !!! This change is NOT compatible to UPDATE exiting apps! + As of this commit the "id" XML attribute is no longer used as the unique token because its value cannot be guaranteed to be unique by the provider of the schedule XML. See voc/schedule#63. + Instead the "guid" XML attribute is used which guarantees unique values. + To keep this migration to a minimum only the value of the Session#sessionId field is changed. The value of the new primary key (auto-incrementing, unique through the "guid" column) is written into the "sessionId" field when a Session is queried from the database. See SessionsDatabaseRepository. + By this the value of the "id" XML attribute becomes unused hence the deprecation of the SESSION_ID database column.
Bei der GPN 2024 existieren erneut doppelte IDs für Events im originalen (nicht aggregierten) Fahrplan. https://cfp.gulas.ch/gpn22/schedule/export/schedule.xml Es handelt sich dabei um Wiederholungstermine (Workshops). Hier ist bspw. |
Dieser issue sieht verwandt aus: pretalx/pretalx#762 z.K. @rixx |
Might be fixed by cbf2fe479. |
I noticed that the latest version of the 36c3 everything.schedule.xml contains sessions which have the same
<event ... id="886">
assigned.and
To my understanding this should not be the case.
Related
The text was updated successfully, but these errors were encountered: