updated_on column of repositories table required

Issue #134 resolved
Michael JasonSmith
created an issue

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;

Comments (6)

  1. Mads Kiilerich

    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?

  2. Michael JasonSmith reporter

    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:

    1. Create a new database
    2. Dump the RhodeCode 1.3.5beta database
    3. Restore the dumped database into the newly created database
    4. Follow one time conversion instructions
    5. Iterate through the errors, fixing the tables.
  3. Mads Kiilerich

    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 .

  4. Michael JasonSmith reporter

    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.

  5. Log in to comment