Skip to content
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

Open
johnjohndoe opened this issue Mar 20, 2020 · 14 comments
Open

Duplicate event ids (36C3, GPN22) #63

johnjohndoe opened this issue Mar 20, 2020 · 14 comments

Comments

@johnjohndoe
Copy link
Collaborator

I noticed that the latest version of the 36c3 everything.schedule.xml contains sessions which have the same <event ... id="886"> assigned.

<event guid="8115abea-d1c8-59a6-8060-8f773de66a5d" id="886">
    <logo>/media/36c3/images/AHFVXQ/B4B4939E-70E5-43BC-A828-0D69997036CB.jpeg</logo>
    <date>2019-12-29T16:00:00+01:00</date>
    <start>16:00</start>
    <duration>01:00</duration>
    <room>Sendetisch</room>
    <slug>AHFVXQ</slug>
    <url>https://fahrplan.das-sendezentrum.de/36c3/talk/AHFVXQ/</url>
    <title>Brainflicks Special: Star Wars</title>
    <subtitle/>
    <track>Sendetisch</track>
    <type>Normale Länge</type>
    <language>de</language>
    <abstract>Die Saga geht zu Ende. Christiane und Julius lassen die letzte Episode 9 und alle vorherigen Revue passieren.</abstract>
    <description>Die Saga geht zu Ende. Christiane und Julius lassen die letzte Episode 9 und alle vorherigen Revue passieren.</description>
    <recording>
        <license/>
        <optout>false</optout>
    </recording>
    <persons>
        <person id="106">Christiane Attig</person>
        <person id="147">Julius</person>
    </persons>
    <links/>
    <attachments/>
    <answers/>
</event>

and

<event guid="4552e4ec-4400-5376-a845-9a60d956887b" id="886">
    <logo/>
    <date>2019-12-29T21:30:00+01:00</date>
    <start>21:30</start>
    <duration>02:00</duration>
    <room>headnut</room>
    <slug>BJYYE7</slug>
    <url>https://talks.komona.org/36c3/talk/BJYYE7/</url>
    <title>Documentary Photography Workshop - Story development</title>
    <subtitle/>
    <track/>
    <type>Workshop</type>
    <language>en</language>
    <abstract>Story development workshop - idea, conceptualisation, planning, shooting, editing</abstract>
    <description>Story development workshop - idea, conceptualisation, planning, shooting, editing</description>
    <recording>
        <license/>
        <optout>false</optout>
    </recording>
    <persons>
        <person id="82">k8</person>
    </persons>
    <links/>
    <attachments/>
    <answers/>
</event>

To my understanding this should not be the case.

Related

@saerdnaer
Copy link
Member

Das passiert immer wenn wir uns bei der Anzahl der Talks pro Quelle verschätzen, das Skript warnt zur Runtime auch das das passiert:
http://data.c3voc.de/36C3/log.txt

Requesting https://talks.komona.org/36c3/schedule/export/schedule.json
  version: 0.32
  contains 91 events, with local ids from 2 to 94
    after adding the offset, ids reach from 802 to 894
  success
Requesting https://fahrplan.das-sendezentrum.de/36c3/schedule/export/schedule.json
  version: 4.5
  contains 55 events, with local ids from 83 to 143
    after adding the offset, ids reach from 883 to 943
  WARNING: schedule "sendezentrum" has ID overlap with previous schedule
  success

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?

@johnjohndoe
Copy link
Collaborator Author

johnjohndoe commented Mar 20, 2020

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.

@johnjohndoe
Copy link
Collaborator Author

zur Kenntnis @ideadapt!

@saerdnaer
Copy link
Member

@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?

@johnjohndoe
Copy link
Collaborator Author

@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?

@saerdnaer
Copy link
Member

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...

@saerdnaer saerdnaer changed the title Duplicate event id Duplicate event ids (36C3) Sep 14, 2020
@johnjohndoe
Copy link
Collaborator Author

johnjohndoe commented Sep 14, 2020

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.

@saerdnaer
Copy link
Member

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.

additional_schedule_urls = [
{ 'name': 'lounges', 'url': 'https://fahrplan.events.ccc.de/congress/2019/Lineup/schedule.json', 'id_offset': None},
{ 'name': 'chaos-west', 'url': 'https://fahrplan.chaos-west.de/36c3/schedule/export/schedule.json', 'id_offset': 100},
{ 'name': 'open-infra', 'url': 'https://talks.oio.social/36c3-oio/schedule/export/schedule.json', 'id_offset': 200},
{ 'name': 'wikipaka', 'url': 'https://cfp.verschwoerhaus.de/36c3/schedule/export/schedule.json', 'id_offset': 500},
{ 'name': 'chaoszone', 'url': 'https://cfp.chaoszone.cz/36c3/schedule/export/schedule.json', 'id_offset': 700},
{ 'name': 'komona', 'url': 'https://talks.komona.org/36c3/schedule/export/schedule.json', 'id_offset': 800,
'options': { 'room-prefix': '1Komona '}
},
{ 'name': 'sendezentrum', 'url': 'https://fahrplan.das-sendezentrum.de/36c3/schedule/export/schedule.json', 'id_offset': 800},
# generated wiki event id's start from 1000
{ 'name': 'lightning', 'url': 'https://c3lt.de/36c3/schedule/export/schedule.json', 'id_offset': 3000},
{ 'name': 'art-play', 'url': 'https://stage.artesmobiles.art/36c3/schedule/export/schedule.json', 'id_offset': 4100},
{ 'name': 'cdc', 'url': 'https://frab.riat.at/en/36C3/public/schedule.json', 'id_offset': 4200},
# main schedule local ids's start at about 10.000
]

@johnjohndoe
Copy link
Collaborator Author

z.K. Ich habe mal einen Issue für die Migration angelegt. Siehe EventFahrplan/EventFahrplan#319.

@johnjohndoe
Copy link
Collaborator Author

Bei meiner Arbeit/Tests an der Umstellung habe ich gemerkt, dass die guid auch nicht eindeutig vergeben ist. Gibt es da einen Fehler in der Erzeugung der guid? Ich habe im aktuellen 36C3 Fahrplan drei Doppelungen gefunden:

  • 81f5f0c4-3d35-522c-8f1c-c8825b92f00a
  • bf48fa55-92a1-5481-a14a-f77cc0d4fccb
  • 4f5c1cc5-ad99-52dc-89cd-699eae66bcb8

Dabei handelt es sich um Workshops, die zum gleichen Thema stattfinden - aber zu unterschiedlichen Uhrzeiten. Ich vermute, die Berechnung der guid ist deterministisch und bezieht den Zeitstempel nicht mit ein, aber Felder wie <title>, abstract, ... - hier eine Beispiel-Doppelung:

<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 &amp; 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 &amp; 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 guids erzeugt, selbst eine Kontrolle auf Doppelungen vornimmt - bspw. per "Set" Datenstruktur - und entsprechend reagiert. Damit könnte vermieden werden, dass sich Apps oder andere Skripte in der Verarbeitungspipeline mit dem Fehler auseinandersetzen müssen.

johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Dec 19, 2020
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Dec 21, 2020
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Dec 21, 2020
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Dec 23, 2020
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Dec 23, 2020
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Dec 26, 2020
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Dec 28, 2020
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Mar 28, 2021
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Apr 13, 2021
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Apr 23, 2021
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Jul 1, 2021
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Jul 30, 2021
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Aug 3, 2021
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Sep 9, 2021
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Sep 25, 2021
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Oct 21, 2021
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Nov 8, 2021
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Dec 20, 2021
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Dec 21, 2021
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Jan 26, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Feb 3, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Apr 8, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Apr 30, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Jul 10, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Jul 22, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Sep 2, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Sep 7, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Sep 22, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Sep 22, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Nov 25, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Dec 17, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Dec 22, 2022
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Jan 15, 2023
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Feb 12, 2023
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Mar 10, 2023
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Apr 19, 2023
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Apr 21, 2023
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue May 24, 2023
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Jul 1, 2023
!!! 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.
johnjohndoe added a commit to EventFahrplan/EventFahrplan that referenced this issue Dec 6, 2023
!!! 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.
@johnjohndoe
Copy link
Collaborator Author

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. Spliceworkshop - Das Löten der Glasfaser mit der ID 308 drei mal enthalten und auf mehrere Tage verteilt.

@johnjohndoe johnjohndoe changed the title Duplicate event ids (36C3) Duplicate event ids (36C3, GPN22) May 31, 2024
@johnjohndoe
Copy link
Collaborator Author

Dieser issue sieht verwandt aus: pretalx/pretalx#762

z.K. @rixx

@rixx
Copy link

rixx commented May 31, 2024

Might be fixed by cbf2fe479.

@johnjohndoe
Copy link
Collaborator Author

pretalx/pretalx@cbf2fe4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants