Hi, While adding a timestamp to the borrowers table, I ran into the trouble of ambiguous column names when querying multiple tables. See BZ 10459. Until now we added timestamps to several tables while just naming them "timestamp". Adding more timestamps will be increasingly difficult since we have to check all SQL queries that reference timestamp (from another table) and the table at hand. So I now consider adding borrowertimestamp, or bortimestamp (ugly but shorter). Any thoughts about doing this in some consistent manner? Marcel
Hi Marcel I think we don't need to make columns unique across the whole db just when selecting do select borrowers.timestamp as something. DBIx::Class helps us with this also Just my 2 cents Chris
Hi, On Wed, Nov 12, 2014 at 10:35 AM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
I think we don't need to make columns unique across the whole db just when selecting do select borrowers.timestamp as something. DBIx::Class helps us with this also
I agree with Chris. In legacy code, doing a "select *" from a join on multiple tables is should be discouraged, so using the addition of a new column to locate cases of these to stamp out is preferable. The alternative of using a distinct column name has the problem of making the writing of more general templates and classes more difficult. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Agreed with Galen and Chris. DBIC should be able to handle this. Also, distinct column names would make joins more difficult when writing it out by hand (and for DBIC I think). David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Galen Charlton Sent: Thursday, 13 November 2014 5:39 AM To: Chris Cormack Cc: Koha Devel Subject: Re: [Koha-devel] Ambiguous column names
Hi,
On Wed, Nov 12, 2014 at 10:35 AM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
I think we don't need to make columns unique across the whole db just when selecting do select borrowers.timestamp as something. DBIx::Class helps us with this also
I agree with Chris. In legacy code, doing a "select *" from a join on multiple tables is should be discouraged, so using the addition of a new column to locate cases of these to stamp out is preferable. The alternative of using a distinct column name has the problem of making the writing of more general templates and classes more difficult.
Regards,
Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha- community.org/ bugs : http://bugs.koha-community.org/
Marcel de Rooy schreef op wo 12-11-2014 om 14:58 [+0000]:
While adding a timestamp to the borrowers table,
What does timestamp mean? Would more granularity be a good thing? I'm thinking something like "created" and "updated". On the other hand, maybe it's overkill. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
I think the best option, if we were to change away from timestamp, would have to be "lastmodified", as timestamp types will get updated after every insert/update, I believe. But since they'd all be called "lastmodified", changing it from "timestamp" would become a bit moot, I think. Unless we used datetime types in the database and relied on the code to provide the correct date rather than the database (as it does with the timestamp type). David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Robin Sheat Sent: Thursday, 13 November 2014 9:34 AM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Ambiguous column names
Marcel de Rooy schreef op wo 12-11-2014 om 14:58 [+0000]:
While adding a timestamp to the borrowers table,
What does timestamp mean? Would more granularity be a good thing? I'm thinking something like "created" and "updated". On the other hand, maybe it's overkill.
-- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
David Cook schreef op do 13-11-2014 om 12:12 [+1100]:
I think the best option, if we were to change away from timestamp, would have to be "lastmodified", as timestamp types will get updated after every insert/update, I believe. But since they'd all be called "lastmodified", changing it from "timestamp" would become a bit moot, I think.
Well, I was thinking both, "created" and "updated." So you know when the record was created, and when it was last changed. Both very handy for simple auditing or bug finding. It's possible to have a timestamp field that is initialised to the current date automatically on creation, and another that is auto updated. http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html This would nicely mean that there's no code at all in Koha required to maintain this. Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the ground, anything is better than nothing :) -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
Thanks for the link! It's rather interesting! Yeah, I think "created" and "updated" columns would be useful. I think we already use them in "biblio", although maybe the code in Koha is setting those rather than the database. It would be handy to either auto-initialize/auto-update, or just pass null once to a "created" column and every time to an "updated" column. I'm happy to drop it, but thanks for the clarification :D. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Robin Sheat Sent: Thursday, 13 November 2014 1:03 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Ambiguous column names
David Cook schreef op do 13-11-2014 om 12:12 [+1100]:
I think the best option, if we were to change away from timestamp, would have to be "lastmodified", as timestamp types will get updated after every insert/update, I believe. But since they'd all be called "lastmodified", changing it from "timestamp" would become a bit moot, I think.
Well, I was thinking both, "created" and "updated." So you know when the record was created, and when it was last changed. Both very handy for simple auditing or bug finding.
It's possible to have a timestamp field that is initialised to the current date automatically on creation, and another that is auto updated.
http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html
This would nicely mean that there's no code at all in Koha required to maintain this.
Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the ground, anything is better than nothing :)
-- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
Haha, funny. I tried to do that 2 days ago and... it does not work. create table test( created timestamp not null default current_timestamp, updated timestamp not null default current_timestamp on update current_timestamp ); ERROR 1293 (HY000): Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause The solution would be to create a trigger... MySQL-- So maybe with a datetime? Hum, yes maybe, but only from MySQL 5.6.5 ( https://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html) MySQL-- 2014-11-13 4:10 GMT+01:00 David Cook <dcook@prosentient.com.au>:
Thanks for the link! It's rather interesting!
Yeah, I think "created" and "updated" columns would be useful. I think we already use them in "biblio", although maybe the code in Koha is setting those rather than the database. It would be handy to either auto-initialize/auto-update, or just pass null once to a "created" column and every time to an "updated" column.
I'm happy to drop it, but thanks for the clarification :D.
David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Robin Sheat Sent: Thursday, 13 November 2014 1:03 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Ambiguous column names
David Cook schreef op do 13-11-2014 om 12:12 [+1100]:
I think the best option, if we were to change away from timestamp, would have to be "lastmodified", as timestamp types will get updated after every insert/update, I believe. But since they'd all be called "lastmodified", changing it from "timestamp" would become a bit moot, I think.
Well, I was thinking both, "created" and "updated." So you know when the record was created, and when it was last changed. Both very handy for simple auditing or bug finding.
It's possible to have a timestamp field that is initialised to the current date automatically on creation, and another that is auto updated.
http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html
This would nicely mean that there's no code at all in Koha required to maintain this.
Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the ground, anything is better than nothing :)
-- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Ahhh, yeah, I did read that you couldn’t have multiple columns with CURRENT_TIMESTAMP. The wording was a bit vague though so I was going to try it out. Good to know. I suppose the thing to do then is use TIMESTAMP for `updated` (with DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP) and then DATETIME for `created` and just use a NOW() in the original INSERT query. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Jonathan Druart Sent: Thursday, 13 November 2014 7:27 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Ambiguous column names Haha, funny. I tried to do that 2 days ago and... it does not work. create table test( created timestamp not null default current_timestamp, updated timestamp not null default current_timestamp on update current_timestamp ); ERROR 1293 (HY000): Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause The solution would be to create a trigger... MySQL-- So maybe with a datetime? Hum, yes maybe, but only from MySQL 5.6.5 (https://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html) MySQL-- 2014-11-13 4:10 GMT+01:00 David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> >: Thanks for the link! It's rather interesting! Yeah, I think "created" and "updated" columns would be useful. I think we already use them in "biblio", although maybe the code in Koha is setting those rather than the database. It would be handy to either auto-initialize/auto-update, or just pass null once to a "created" column and every time to an "updated" column. I'm happy to drop it, but thanks for the clarification :D. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> [mailto:koha-devel- <mailto:koha-devel-> bounces@lists.koha-community.org <mailto:bounces@lists.koha-community.org> ] On Behalf Of Robin Sheat Sent: Thursday, 13 November 2014 1:03 PM To: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Ambiguous column names
David Cook schreef op do 13-11-2014 om 12:12 [+1100]:
I think the best option, if we were to change away from timestamp, would have to be "lastmodified", as timestamp types will get updated after every insert/update, I believe. But since they'd all be called "lastmodified", changing it from "timestamp" would become a bit moot, I think.
Well, I was thinking both, "created" and "updated." So you know when the record was created, and when it was last changed. Both very handy for simple auditing or bug finding.
It's possible to have a timestamp field that is initialised to the current date automatically on creation, and another that is auto updated.
http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html
This would nicely mean that there's no code at all in Koha required to maintain this.
Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the ground, anything is better than nothing :)
-- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 <tel:%2B64%204%20803%202204> GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
https://github.com/biblibre/hea-ws/commit/9b48cc364547e0f779f8369946fb8371c7... It's exactly what I did :) 2014-11-14 1:20 GMT+01:00 David Cook <dcook@prosentient.com.au>:
Ahhh, yeah, I did read that you couldn’t have multiple columns with CURRENT_TIMESTAMP. The wording was a bit vague though so I was going to try it out. Good to know.
I suppose the thing to do then is use TIMESTAMP for `updated` (with DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP) and then DATETIME for `created` and just use a NOW() in the original INSERT query.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St, Ultimo, NSW 2007
*From:* koha-devel-bounces@lists.koha-community.org [mailto: koha-devel-bounces@lists.koha-community.org] *On Behalf Of *Jonathan Druart *Sent:* Thursday, 13 November 2014 7:27 PM
*To:* koha-devel@lists.koha-community.org *Subject:* Re: [Koha-devel] Ambiguous column names
Haha, funny. I tried to do that 2 days ago and... it does not work.
create table test( created timestamp not null default current_timestamp, updated timestamp not null default current_timestamp on update current_timestamp ); ERROR 1293 (HY000): Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause
The solution would be to create a trigger... MySQL--
So maybe with a datetime? Hum, yes maybe, but only from MySQL 5.6.5 ( https://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html)
MySQL--
2014-11-13 4:10 GMT+01:00 David Cook <dcook@prosentient.com.au>:
Thanks for the link! It's rather interesting!
Yeah, I think "created" and "updated" columns would be useful. I think we already use them in "biblio", although maybe the code in Koha is setting those rather than the database. It would be handy to either auto-initialize/auto-update, or just pass null once to a "created" column and every time to an "updated" column.
I'm happy to drop it, but thanks for the clarification :D.
David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Robin Sheat Sent: Thursday, 13 November 2014 1:03 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Ambiguous column names
David Cook schreef op do 13-11-2014 om 12:12 [+1100]:
I think the best option, if we were to change away from timestamp, would have to be "lastmodified", as timestamp types will get updated after every insert/update, I believe. But since they'd all be called "lastmodified", changing it from "timestamp" would become a bit moot, I think.
Well, I was thinking both, "created" and "updated." So you know when the record was created, and when it was last changed. Both very handy for simple auditing or bug finding.
It's possible to have a timestamp field that is initialised to the current date automatically on creation, and another that is auto updated.
http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html
This would nicely mean that there's no code at all in Koha required to maintain this.
Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the ground, anything is better than nothing :)
-- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Actually, after looking at the `issues` and `reserves` tables, I'm really in favour of getting rid of "timestamp" columns and renaming them more contextually. In the case of `reserves`, I have no idea what `timestamp` means. There's already `reservedate`, `notificationdate`, `reminderdate`, `waitingdate`. It's probably `updated` in that case? As `reservedate` would be `created`? In the case of `issues`, there is already `date_due`, `lastreneweddate`, `returndate`, `issuedate`. I imagine `issuedate` would be `created`. It looks like `timestamp` is `updated` . As I look, it usually matches `lastreneweddate` although timestamp has time while the other does not. I wonder how much we actually use `timestamp` in the code... Of course, if we do change column names, then we'll be screwing up a lot of the existing SQL reports that people have out there which may or may not use timestamp for dating... David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Robin Sheat Sent: Thursday, 13 November 2014 1:03 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Ambiguous column names
David Cook schreef op do 13-11-2014 om 12:12 [+1100]:
I think the best option, if we were to change away from timestamp, would have to be "lastmodified", as timestamp types will get updated after every insert/update, I believe. But since they'd all be called "lastmodified", changing it from "timestamp" would become a bit moot, I think.
Well, I was thinking both, "created" and "updated." So you know when the record was created, and when it was last changed. Both very handy for simple auditing or bug finding.
It's possible to have a timestamp field that is initialised to the current date automatically on creation, and another that is auto updated.
http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html
This would nicely mean that there's no code at all in Koha required to maintain this.
Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the ground, anything is better than nothing :)
-- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
I think it should be yellow Chris On 13/11/2014 4:52 pm, "David Cook" <dcook@prosentient.com.au> wrote:
Actually, after looking at the `issues` and `reserves` tables, I'm really in favour of getting rid of "timestamp" columns and renaming them more contextually.
In the case of `reserves`, I have no idea what `timestamp` means. There's already `reservedate`, `notificationdate`, `reminderdate`, `waitingdate`. It's probably `updated` in that case? As `reservedate` would be `created`?
In the case of `issues`, there is already `date_due`, `lastreneweddate`, `returndate`, `issuedate`. I imagine `issuedate` would be `created`. It looks like `timestamp` is `updated` . As I look, it usually matches `lastreneweddate` although timestamp has time while the other does not.
I wonder how much we actually use `timestamp` in the code...
Of course, if we do change column names, then we'll be screwing up a lot of the existing SQL reports that people have out there which may or may not use timestamp for dating...
David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Robin Sheat Sent: Thursday, 13 November 2014 1:03 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Ambiguous column names
David Cook schreef op do 13-11-2014 om 12:12 [+1100]:
I think the best option, if we were to change away from timestamp, would have to be "lastmodified", as timestamp types will get updated after every insert/update, I believe. But since they'd all be called "lastmodified", changing it from "timestamp" would become a bit moot, I think.
Well, I was thinking both, "created" and "updated." So you know when the record was created, and when it was last changed. Both very handy for simple auditing or bug finding.
It's possible to have a timestamp field that is initialised to the current date automatically on creation, and another that is auto updated.
http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html
This would nicely mean that there's no code at all in Koha required to maintain this.
Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the ground, anything is better than nothing :)
-- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I’m partial to blue myself :p. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007 From: Chris Cormack [mailto:chris@bigballofwax.co.nz] Sent: Thursday, 13 November 2014 2:59 PM To: David Cook Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Ambiguous column names I think it should be yellow Chris On 13/11/2014 4:52 pm, "David Cook" <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote: Actually, after looking at the `issues` and `reserves` tables, I'm really in favour of getting rid of "timestamp" columns and renaming them more contextually. In the case of `reserves`, I have no idea what `timestamp` means. There's already `reservedate`, `notificationdate`, `reminderdate`, `waitingdate`. It's probably `updated` in that case? As `reservedate` would be `created`? In the case of `issues`, there is already `date_due`, `lastreneweddate`, `returndate`, `issuedate`. I imagine `issuedate` would be `created`. It looks like `timestamp` is `updated` . As I look, it usually matches `lastreneweddate` although timestamp has time while the other does not. I wonder how much we actually use `timestamp` in the code... Of course, if we do change column names, then we'll be screwing up a lot of the existing SQL reports that people have out there which may or may not use timestamp for dating... David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> [mailto:koha-devel- <mailto:koha-devel-> bounces@lists.koha-community.org <mailto:bounces@lists.koha-community.org> ] On Behalf Of Robin Sheat Sent: Thursday, 13 November 2014 1:03 PM To: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Ambiguous column names
David Cook schreef op do 13-11-2014 om 12:12 [+1100]:
I think the best option, if we were to change away from timestamp, would have to be "lastmodified", as timestamp types will get updated after every insert/update, I believe. But since they'd all be called "lastmodified", changing it from "timestamp" would become a bit moot, I think.
Well, I was thinking both, "created" and "updated." So you know when the record was created, and when it was last changed. Both very handy for simple auditing or bug finding.
It's possible to have a timestamp field that is initialised to the current date automatically on creation, and another that is auto updated.
http://dev.mysql.com/doc/refman/5.1/en/timestamp-initialization.html
This would nicely mean that there's no code at all in Koha required to maintain this.
Anyway, I was just sticking my oar in, I've no desire to bikeshed it into the ground, anything is better than nothing :)
-- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 <tel:%2B64%204%20803%202204> GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Thanks for the replies. I will update the borrower-timestamp report accordingly. I will stick to timestamp for the reasons mentioned. Will have to check/update some queries though to prevent the ambiguous column-error.
Well, I was thinking both, "created" and "updated." So you know when the record was created, and when it was last changed. Both very handy for simple auditing or bug finding.
Sounds good to me, although I do not commit myself to implementing it right now ;) Marcel
participants (6)
-
Chris Cormack -
David Cook -
Galen Charlton -
Jonathan Druart -
Marcel de Rooy -
Robin Sheat