Multiple Eventnames in Database

[GoogleCodeExporter]

Some new Events (not all!) will appear with another eventname some time later. 
The eventnames are names of older entries.
In the Database were stored multiple Attributes "name" with different values 
for only one eventID for those events (check attached file).
All older events were imported via ical files.

The first occurence of the problem is combined with Version 1.7.6. We are using 
the client-server mode.

Original issue reported on code.google.com by Matthias...@googlemail.com on 17 Dec 2013 at 11:12

Attachments:

• db.txt

[GoogleCodeExporter]

it looks like there is no column used as a database-key for the rows in the 
event_attribute_value database. or there is a bug in database-connection/caldav 
import.

Original comment by b.von.st...@gmail.com on 17 Dec 2013 at 11:57

[GoogleCodeExporter]

This may happen, if two rapla server or standalone instances access the same 
database. Because Rapla only reads the database at startup and use it later 
only for storing 

instance1 start and load database
instance2 start and load database
instance1 import from ical and store to database with new eventid 12618 
instance2 new event Analysis 2 created with new eventid 12618 (as instance2 
does not check if the database has been updated from another program or 
instance during runtime so it thinks 12618 is still available) 

Could this have happened?

Original comment by christop...@gmail.com on 17 Dec 2013 at 2:36

[GoogleCodeExporter]

Original comment by christop...@gmail.com on 17 Dec 2013 at 2:37

• Changed state: Accepted

[GoogleCodeExporter]

hmm.. may has happened, have to think about it ;-)

I ve done some more database analysis. In table EVENT_ATTRIBUTE_VALUE were 
Entrys for EVENT_IDs which doesen't exist in EVENT. So for new events that will 
happen again.

To resque our database.. Is it possible to set somwehre in the database a value 
like "next event id to use" ? I know that will not solve the problem itself, 
but like that all new events were not affected by the entries in 
EVENT_ATTRIBUT_VALUE.
(max ID in EVENTS ~12730, max ID in EVENT_ATTRIBUTE_VALUE ~14500)

Original comment by Matthias...@googlemail.com on 17 Dec 2013 at 3:16

[GoogleCodeExporter]

Thx for the update. Forget my old suggestion. My new:

It seems like an old reservation that has been deleted from the EVENT table, 
has not cleaned up the EVENT_ATTRIBUTE_VALUE. I will inspect further, how this 
could happened, if you have a clue or further information keep me posted.

Meanwhile you can checkout 1_7 branch and see if the changes work for you:
I changed rapla sql so that rapla does clean up any data from an object and its 
attributes before storing it again, to prevent the behaviour above. 

http://code.google.com/p/rapla/source/detail?r=82cb626c2d1224f35bb8c12d8d145936e
5456397&name=1_7

Original comment by christop...@gmail.com on 18 Dec 2013 at 10:53

[GoogleCodeExporter]

Tried to reproduce it with mysql, but for me event_attribute_value will be 
deleted when event is deleted. 

Original comment by christop...@gmail.com on 18 Dec 2013 at 11:18

[GoogleCodeExporter]

some more analysis:

All entries in EVENT_ATTRIBUTE_VALUE which are not referenced to an existing 
event, are out of an import of a signle ical file. I remember that we had some 
problems with that file because of some invalid characters in it. We got an 
error message like "can't import file, all changes in db has been deleted".

So I assume that there is the  bug. I think the rollback isn't done correctly...

Original comment by Matthias...@googlemail.com on 18 Dec 2013 at 3:31

[GoogleCodeExporter]

Maybe you got the following:

Error! Database update failed. Because
your database doesn't support transactions, that could lead to
serious failures. Please contact your administrator
immediately!

Do you use Mysql database with or without transactions?
That would explain the situation. When storing multiple events in db rapla 
stores first the attributes then the reservation. If the attribute storage 
failed at some point and there is no transaction support, the situation above 
could be explained.

Then we only need to find the reason why ical import creates data that would 
fail on import. The easiest explenation would be:
Is there a description larger then 20kb?
Because of compatibility issues with older msql versions only 20kb description 
text is supported. I will implement a truncate in the next version.

Original comment by christop...@gmail.com on 19 Dec 2013 at 3:57

[GoogleCodeExporter]

Hi,

it was another error. I just found the execptions in our logfile..

Original comment by Matthias...@googlemail.com on 6 Jan 2014 at 8:47

[GoogleCodeExporter]

forgot to attach the file ;-)

Original comment by Matthias...@googlemail.com on 6 Jan 2014 at 8:48

Attachments:

• error.log

[GoogleCodeExporter]

Seems like a bug in mysql or mysql driver with special characters.

Original comment by christop...@gmail.com on 17 Jan 2014 at 10:49