Add recently updated to list sidebar

[jnovack]

Two notes:

• tstamp is the date last indexing change, not the date of the last modification. (although, it can be equal)
• crdate is the date last updated, not created.

In use here: http://phorkie.ozmonet.com/list

[cweiske]

I'd rather see the the values of both fields fixed to keep their meaning (tstamp = last update, crdate = creation date) instead of seeing the broken behavior being built upon.

[jnovack]

I'm going to counter.

• tstamp should be the last time the indexing was updated.
• crdate should be the creation date of the repo
• modate should be the last modified date (last commit)

You have tstamp being updated in Database/Adapter/ElasticSearch/Indexer.php as time(). I'd like to keep that. This way you can see when something was last indexed, regardless of it was updated or not. tstamp being the timestamp of the elasticsearch RECORD, not the timestamp of the repo.

[cweiske]

Hello Justin,

I'm going to counter.

• tstamp should be the last time the indexing was modified. I'm coming with a mind shaped by TYPO3; it has crdate (creation date of record) and tstamp (last modification date of record) in every database table:)
• crdate should be the creation date of the repo
• modate should be the last modified date (last commit)

You have tstamp being updated in Database/Adapter/ElasticSearch/Indexer.php as time(). I'd like to keep that. This way you can see when something was last indexed, regardless of it was updated or not.

I fail to see the usefulness of the tstamp (last index time) field. Where would one need it?

Regards/Mit freundlichen Grüßen Christian Weiske

-=≡ Geeking around in the name of science since 1982 ≡=-

[jnovack]

Ah, ok. I'm coming from SQL where we add timestamp fields to the db just to see when the record was last updated, regardless of what was done to it or the other date files in the row. It's not a row that's usually requested by the client.

If you want to stick with tstamp and crdate, are they timestamps of the RECORD or the REPO? I'm suggesting tstamp be the last timestamp of the RECORD, whereas crdate and modate be the timestamps of the REPO.

You are already using tstamp as a last index time, I was just keeping it. It helps with debugging the database ensuring the records are being updated appropriately.

What do you want me to correct?

[cweiske]

Hello Justin,

If you want to stick with tstamp and crdate, are they timestamps of the RECORD or the REPO? I'm suggesting tstamp be the last timestamp of the RECORD, whereas crdate and modate be the timestamps of the REPO. Ok.

You are already using tstamp as a last index time, I was just keeping it. It helps with debugging the database ensuring the records are being updated appropriately.

I'd like to see that crdate is logging the repo's real creation date, not first index date, and modate the repo's latest commit date.

Regards/Mit freundlichen Grüßen Christian Weiske

-=≡ Geeking around in the name of science since 1982 ≡=-

[jnovack]

That's going to be tough. Linux does not keep creation dates of files. filectime() is useless, however, filemtime() is still useful for the last commit.

My best idea thus far is to update Repository.php with getFirstCommit(), and getDateOfCommit() functions. I'll start on that.

[jnovack]

I'd like to delete repo-sidebar-updated.htm and change repo-sidebar-list.htm to show last updated repos (not created repos).

After that, I'll smash them all together as 1 commit.

[cweiske]

ok.

[jnovack]

Final Answer.