Closed (fixed)
Project:
Availability Calendars
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
6 Mar 2011 at 19:29 UTC
Updated:
3 Apr 2011 at 21:41 UTC
Accessing a table via MySQL workbench gives me:
Error: `drupal`.`test_availability_calendars_day`: table data is not editable because there is no primary key defined for the table
This probably also means there are no indices, so full tables scans by default for each and every query.
Comments
Comment #1
nicholas.alipaz commentedyes, this could be a resource hog if on a large db. Should definitely fix in 6.x-1.6 release and port to 2.x branches.
Comment #2
fietserwinI would make this issue a bit broader: decide on storage for Availability Calendars.
Add primary index
What fields should be the primary key be composed of and in what order?
Do we need other indices?
Or do we add them as necessary because of new features (searching all nodes that are available between and : #470994: search ).
Duplication and portability
#747036: Add datetime representation of year, month and day to table for querying added a datetime field. However, according to #866340: Remove support for date and time types this is not portable and thus had to be changed in D7 (see also: http://drupal.org/update/modules/6/7#db_specific_types
. Now we are stuck with duplication and portability issues. How can we represent the dates in a way that is both portable and still satisfies #747036: Add datetime representation of year, month and day to table for querying?
Portability may be restricted to: MySQL, PostgreSQL and SQLite, the officially supported databases for D7 (with MS SQL Server in the picture). But apart from the storage types in the various database engines, I am more concerned with querying, especially the type of search query as requested in the above mentioned issues for this module.
Duplication should in my opinion be prevented, thus we should arrive at 1 way of storing the date and remove the others.
Possible ways to solve this:
- Can the date module help us with this issue, it seems that it added a date(time) field in D7 as was removed from core in D7. If so, do we want a dependency on this module?
- Should we use unix timestamps (as core does)?
- Should we go for text using ISO8601 compact form (http://stackoverflow.com/questions/5009246/portable-sql-for-date-arithme...): perfectly sortable and query-able.
- Should we go for DATE, seems to operate fine with the 3 (4 including MS SQL S) supported databases.
- Ignore this: we don't have a problem.
Comment #3
nicholas.alipaz commentedI am personally fine with making date module a dependency and feel it is almost expected from a module such as this. It might also make this module slightly easier to integrate with cck if we go such route in the future.
Comment #4
fietserwinCommitted to 7.x-2.x-dev.
Anyone wanting to back port this to 6.x?