Issue #134: updated_on column of repositories table required

Reported by:	Michael JasonSmith
State:	resolved
Created on:	2015-05-21 17:11
Updated on:	2015-06-19 16:28

Description

Currently

The updated_on column of the repositories table is unconstrained. However, if a row has a updated_on set to NULL then the repositories page fails to render.

Expected

Either

The updated_on column of the repositories table should have a not null constraint, or
Pages that rely on the column should be able to cope with null values.

Traceback

Full traceback in kallithea-last_change-traceback.txt attacked to this issue.

File '...kallithea/data/templates/data_table/_dt_elements.html.py', line 400 in render_last_change
  __M_writer(escape(h.age(last_change)))
File '...kallithea/local/lib/python2.7/site-packages/kallithea/lib/helpers.py', line 428 in <lambda>
  age = lambda  x, y=False: _age(x, y)
File '...kallithea/local/lib/python2.7/site-packages/kallithea/lib/utils2.py', line 374 in age
  if prevdate > now:
TypeError: can't compare datetime.datetime to NoneType

Admission

I was migrating an old RhodeCode system to Kallithea, so admittedly my data is a little odd, which is why I ran into this issue. However, a vanilla Kallithea 0.2.1 install has the identical problematic schema for the repositories table:

 created_on       | timestamp without time zone | 
 updated_on       | timestamp without time zone |

My hack around the issue was to add updated_on data:

update repositories 
  set updated_on = created_on
  where updated_on is null;

Attachments

kallithea-last_change-traceback.txt

Comments

Comment by Mads Kiilerich, on 2015-05-21 18:12

You are mpj17 from irc?

Did the update itself go fine without errors? Which version were you coming from ... and which update steps have you been through in the past? Any problems/hacks in the past?

Comment by Michael JasonSmith, on 2015-05-21 18:30

Yes, I am the same mpj17 that is on IRC.

Once I updated the data that issue went away. I have struck many other issues, but a quick comparison between the schema Kallithea defines by default and what is in my migrated database (PostgreSQL, for what it is worth) has allowed me to keep making progress. I am now up to a stage where a repo summary page is shown, so I am fairly happy with that. (It is also an interesting learning experience to see how others structure their data.)

My migration steps were:

Create a new database
Dump the RhodeCode 1.3.5beta database
Restore the dumped database into the newly created database
Follow one time conversion instructions
Iterate through the errors, fixing the tables.

Comment by Thomas De Schampheleire, on 2015-05-25 19:50

@kiilerix what to do with this?

Comment by Mads Kiilerich, on 2015-05-25 20:19

The old beta version might be inconsistent and without any automatic upgrading forward - especially if there were bugs in the beta version of the 1.3.5 upgrade step.

It would be interesting to know if upgrading to rhodecode 1.7.2 has the same problem by itself or when upgrading from that to latest Kallithea version.

If the problem also is seen when upgrading from a clean 1.3.5, we should fix the upgrade step - http://lists.sfconservancy.org/pipermail/kallithea-general/2015q2/000978.html .

Comment by Michael JasonSmith, on 2015-06-03 22:36

Sorry, I failed to make myself clear. I am concerned that the updated_on column of repositories table is unconstrained, and it should have a not null constraint. I am unconcerned about having to manually poke tables to perform the upgrade: it was from an ancient and obscure version.

Comment by Mads Kiilerich, on 2015-06-19 16:28

Pushed fix to stable.

Kallithea issues archive