The schema module is reporting these discrepancies

Screenshot: http://awesomescreenshot.com/02ahud96e

FIELD_DATA_FIELD_DATE_TIME
column field_date_time_value - difference on: type
declared: array('description' => 'TODO: please describe this field!', 'type' => 'DATETIME', 'not null' => FALSE)
actual: array('description' => 'TODO: please describe this field!', 'type' => 'datetime', 'not null' => FALSE)
column field_date_time_value2 - difference on: type
declared: array('description' => 'TODO: please describe this field!', 'type' => 'DATETIME', 'not null' => FALSE)
actual: array('description' => 'TODO: please describe this field!', 'type' => 'datetime', 'not null' => FALSE)

HIDEFIELD_REVISION_FIELD_DATE_TIME
column field_date_time_value - difference on: type
declared: array('description' => 'TODO: please describe this field!', 'type' => 'DATETIME', 'not null' => FALSE)
actual: array('description' => 'TODO: please describe this field!', 'type' => 'datetime', 'not null' => FALSE)
column field_date_time_value2 - difference on: type
declared: array('description' => 'TODO: please describe this field!', 'type' => 'DATETIME', 'not null' => FALSE)
actual: array('description' => 'TODO: please describe this field!', 'type' => 'datetime', 'not null' => FALSE)

HIDEFIELD_DATA_FIELD_REGISTRATION_DEADLINE
column field_registration_deadline_value - difference on: type
declared: array('description' => 'TODO: please describe this field!', 'type' => 'DATETIME', 'not null' => FALSE)
actual: array('description' => 'TODO: please describe this field!', 'type' => 'datetime', 'not null' => FALSE)

HIDEFIELD_REVISION_FIELD_REGISTRATION_DEADLINE
column field_registration_deadline_value - difference on: type
declared: array('description' => 'TODO: please describe this field!', 'type' => 'DATETIME', 'not null' => FALSE)
actual: array('description' => 'TODO: please describe this field!', 'type' => 'datetime', 'not null' => FALSE)
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bryancasler’s picture

I'm hunting down these discrepancies to squish this bug that is generating hundreds of notices a day on my site.

#1212842: Undefined property: stdClass / line 775 of ctools/includes/export.inc

yched’s picture

Project: Drupal core » Date
Version: 7.4 » 7.x-2.x-dev
Component: field system » Date CCK Field

Bumping over to Date module.

KarenS’s picture

Project: Date » Schema
Version: 7.x-2.x-dev » 7.x-1.x-dev
Component: Date CCK Field » Code

Bumping to Schema module. There is absolutely nothing I can do to keep Schema from reporting these as errors. When the datetime field was removed from core the current method became the only way I can create a datetime field.

I don't think Schema should be reporting this as an error.

bryancasler’s picture

Bump

pobster’s picture

Are you not reading the issue properly? It's simply saying that it should be lowercase...

Pobster

pobster’s picture

pobster’s picture

Project: Schema » Date
Status: Active » Needs review

If anyone is interested;

# Running schema compare.
SSH: drush -r '/srv/drupal/downtonabbey/releases/current' -l http://downtonabbey schema-compare
> localhost
Database Schema Comparison
 States    Counts 
 Match     198    
 Mismatch  0      
 Missing   0      
 Extra     0   

w00t

Pobster

KarenS’s picture

MYSQL expects uppercase. All other types we send to MYSQL are uppercase. Have you actually tested this patch? You have to see if it will properly create new tables with that change.

pobster’s picture

Yes I have tested that patch. Schema passes 'mismatch' fine (which is all this issue refers to), the date module still works fine (MySQL doesn't care) but you do still get the warnings;

Field field_data_field_episode_publish_date.field_episode_publish_date_value: no Schema type for mysql type datetime.   [warning]
Field field_data_field_episode_tx_date.field_episode_tx_date_value: no Schema type for mysql type datetime.   [warning]
Field field_revision_field_episode_publish_date.field_episode_publish_date_value: no Schema type for mysql type datetime.   [warning]
Field field_revision_field_episode_tx_date.field_episode_tx_date_value: no Schema type for mysql type datetime.   [warning]
field_data_field_episode_publish_date.field_episode_publish_date_value: no  type for Schema type datetime:normal.   [warning]
Field field_data_field_episode_publish_date.field_episode_publish_date_value: no Schema type for  type datetime.   [warning]

I'm less bothered about this though, it's the mismatch that matters. Anyways, can force the warnings to be hidden with variable_set('schema_suppress_type_warnings', TRUE).

edit:

mysql> DESCRIBE field_revision_field_testme;
+--------------------+------------------+------+-----+---------+-------+
| Field              | Type             | Null | Key | Default | Extra |
+--------------------+------------------+------+-----+---------+-------+
| entity_type        | varchar(128)     | NO   | PRI |         |       |
| bundle             | varchar(128)     | NO   | MUL |         |       |
| deleted            | tinyint(4)       | NO   | PRI | 0       |       |
| entity_id          | int(10) unsigned | NO   | PRI | NULL    |       |
| revision_id        | int(10) unsigned | NO   | PRI | NULL    |       |
| language           | varchar(32)      | NO   | PRI |         |       |
| delta              | int(10) unsigned | NO   | PRI | NULL    |       |
| field_testme_value | datetime         | YES  |     | NULL    |       |
+--------------------+------------------+------+-----+---------+-------+

Pobster

cvining’s picture

OK folks, I'm seeing these issues too, and it seems like this isn't even new.

There are actually two separate issues here

Issue #1) The mismatch Uppercase vs. lowercase: datetime vs. DATETIME

I can confirm the patch eliminates the actual:'datetime' vs. declared: 'DATETIME' error.

It looks to me like you can tell MySQL to set the type in either upper or lowercase, and it makes no difference. But when the type is reported back thru drupal, it comes back lower case. So Schema will report a mismatched table unless the declaration in the date.install file is lowercase. It wasn't. With the patch, it is. And, BTW, all the other variables were declared as lowercase. So far so good: with that patch Date Module is OK, so far as this mismatch issue.

Issue #2) no Schema type for mysql type datetime

Unfortunately, the Schema module seems quite correct to report this as a warning. datetime is NOT a D7 datatype. It looks like Schema uses the API call

getFieldTypeMap()

the source for that function is here:

http://api.drupal.org/api/drupal/includes--database--mysql--schema.inc/f...

and, lo and behold, datetime is not one of the types. Datetime has indeed been removed from core, and after some rather lengthy discussion:

http://drupal.org/node/866340

So in this respect, the Date module seems non-compliant with the Drupal Way.

So the module works with my setup, and I'll go with it for now.

It's a tricky one. Core Drupal makes choices for reasons of theirs, which seems mainly a 'portability' argument, so that D7 can run with all sorts of different DB servers. Module writers are free to have slightly different goals, and write more MySQL-centric applications. It's the stuff that schisms are made of.

At least I know to ignore these warnings, and move on with things.

Thanks!

-- Cronin

marcoscano’s picture

subscribe

michaelfavia’s picture

Status: Needs review » Reviewed & tested by the community

Patch applies cleanly and resolves the error. This obviously doesnt fix the larger noncompliance 'datetime' schemae type issue but i cant speak to that.

shaisamuel’s picture

I am confused. I have drupal 7.9, Date 7.x-2.x-dev (2011-Sep-08), 7.x-1.x-dev (2011-Aug-22).

I the patch is implemented on my site, but I still get the error message:

field_data_field_date.field_date_value: no type for Schema type datetime:normal.
field_data_field_date.field_date_value2: no type for Schema type datetime:normal.
field_revision_field_date.field_date_value: no type for Schema type datetime:normal.
field_revision_field_date.field_date_value2: no type for Schema type datetime:normal.
field_data_field_period_begining.field_period_begining_value: no type for Schema type datetime:normal.
field_revision_field_period_begining.field_period_begining_value: no type for Schema type datetime:normal.
field_data_field_period_ending.field_period_ending_value: no type for Schema type datetime:normal.
field_revision_field_period_ending.field_period_ending_value: no type for Schema type datetime:normal.
pobster’s picture

No, no - read my comments above. You *do* still get those because Drupal doesn't know about them. However, there's a variable you can change to ignore these messages (in Schema module settings).

The only thing we're suppressing here is the Schema module mismatch error, if you look at the output - you'll see you're no longer getting any.

Pobster

KarenS’s picture

Status: Reviewed & tested by the community » Needs review

Date module is not 'non-compliant' with Drupal core, it is just using a database type not provided by core. Core does not and will not provide all database types out of the box and the datetime field is one of the ones they chose not to include. The database API is designed to support other types. I think it is a bug that Schema reports this as a discrepancy. I think it is a bug that Schema module reports an error on the type just because of the difference in case. I think it is silly that I had to rework the module after core was frozen to add this back in and now I have to waste more time fixing something that isn't a 'bug' at all because of Schema module. But I will do it anyway.

The change in case needs to be tested on a new install to be sure the right database types are created with the change. Create a new install and then create a datetime field and be sure the field is created properly and that you can create and save dates correctly. Applying the change to a site where the date fields are already created is not enough to make this ready to commit.

Once that is confirmed we can commit this.

pobster’s picture

I can confirm it, our CI process has a section which installs from scratch every day and reports back its findings;

drush -r '/tmp/jenkins/workspace/CI/drupal_core/drupal' -l http://xxxxx schema-compare
Database Schema Comparison
 States    Counts 
 Match     212    
 Mismatch  1      
 Missing   0      
 Extra     0      

Field                                                                  [warning]
field_data_field_episode_publish_date.field_episode_publish_date_value:
no Schema type for mysql type datetime.
Field field_data_field_episode_tx_date.field_episode_tx_date_value:    [warning]
no Schema type for mysql type datetime.
Field                                                                  [warning]
field_revision_field_episode_publish_date.field_episode_publish_date_value:
no Schema type for mysql type datetime.
Field                                                                  [warning]
field_revision_field_episode_tx_date.field_episode_tx_date_value: no
Schema type for mysql type datetime.
field_data_field_episode_publish_date.field_episode_publish_date_value:  [warning]
no  type for Schema type datetime:normal.
Field                                                                  [warning]
field_data_field_episode_publish_date.field_episode_publish_date_value:
no Schema type for  type datetime.
field_revision_field_episode_publish_date.field_episode_publish_date_value:  [warning]
no  type for Schema type datetime:normal.
Field                                                                  [warning]
field_revision_field_episode_publish_date.field_episode_publish_date_value:
no Schema type for  type datetime.
field_data_field_episode_tx_date.field_episode_tx_date_value: no       [warning]
type for Schema type datetime:normal.
Field field_data_field_episode_tx_date.field_episode_tx_date_value:    [warning]
no Schema type for  type datetime.
field_revision_field_episode_tx_date.field_episode_tx_date_value: no   [warning]
type for Schema type datetime:normal.
Field                                                                  [warning]
field_revision_field_episode_tx_date.field_episode_tx_date_value: no
Schema type for  type datetime.

The mismatch is unrelated... And the date fields are fine.

Pobster

KarenS’s picture

Project: Date » Schema
Status: Needs review » Active

Also I originally moved this to the schema issue queue because I still think schema should not be reporting this as an error, so moving it back.

I am going ahead and changing the case in the field type declaration.

StephenRobinson’s picture

I updated to the dev date module which has

'mysql_type' => 'datetime',

but I still get the error:

    *  Field field_data_field_campus_event_when.field_campus_event_when_value: no Schema type for mysql type datetime.
    * Field field_data_field_campus_event_when.field_campus_event_when_value2: no Schema type for mysql type datetime.
    * Field field_revision_field_campus_event_when.field_campus_event_when_value: no Schema type for mysql type datetime.
    * Field field_revision_field_campus_event_when.field_campus_event_when_value2: no Schema type for mysql type datetime.
    * field_data_field_campus_event_when.field_campus_event_when_value: no type for Schema type datetime:normal.
    * Field field_data_field_campus_event_when.field_campus_event_when_value: no Schema type for type datetime.
    * field_data_field_campus_event_when.field_campus_event_when_value2: no type for Schema type datetime:normal.
    * Field field_data_field_campus_event_when.field_campus_event_when_value2: no Schema type for type datetime.
    * field_revision_field_campus_event_when.field_campus_event_when_value: no type for Schema type datetime:normal.
    * Field field_revision_field_campus_event_when.field_campus_event_when_value: no Schema type for type datetime.
    * field_revision_field_campus_event_when.field_campus_event_when_value2: no type for Schema type datetime:normal.
    * Field field_revision_field_campus_event_when.field_campus_event_when_value2: no Schema type for type datetime.

aaaaaaaaaaaaaaahhhhhhhhhhhhhhhh.....................

shaisamuel’s picture

same line #18

KarenS’s picture

Priority: Normal » Critical

Yes, I there is nothing else the Date module can do. The schema module does not seem to be able to handle anything but schemas provided by core. At least that's the best explanation I can come up with. That makes it impossible to use Schema with Date.

KarenS’s picture

For more information for the maintainers, with the change to make the database type lowercase it no longer reports the tables as a mismatch, but it spits out error messages for every one, one error for the 'value' field and one error message for the 'value2' field, both on the admin/config page and on the schema pages.

StephenRobinson’s picture

Yes the schema modules also has

$type = strtolower($type);

will see if I can manage to patch the schema module

StephenRobinson’s picture

debug on function schema_schema_type shows no type:

drupal_set_message($type.'<pre>'.htmlspecialchars(print_r($map,1)).'</pre>');

datetime

Array
(
    [varchar] => varchar:normal
    [char] => char:normal
    [tinytext] => text:small
    [mediumtext] => text:medium
    [longtext] => text:big
    [text] => text:normal
    [tinyint] => int:tiny
    [smallint] => int:small
    [mediumint] => int:medium
    [bigint] => int:big
    [int] => int:normal
    [float] => float:normal
    [double] => float:big
    [decimal] => numeric:normal
    [longblob] => blob:big
    [blob] => blob:normal
)

coming from htdocs/includes/database/mysql/schema.inc: public function getFieldTypeMap() {

StephenRobinson’s picture

I have created a patch, Sorry I cannot access git, error: The requested URL returned error: 403 while accessing http://git.drupal.org/project/schema.git/info/refs, due to proxies and firewalls, so patched 7.x-1.x-dev 2011-Aug-23...

rjbrown99’s picture

Status: Active » Needs review

Changing status as there are patches here.

Feedback on the patches:

#6 resolves the schema module mismatch.

#24 resolves the errors that were displayed to admins.

Both were needed for me to fully fix the issue, but both do appear to work properly.

KarenS’s picture

Status: Needs review » Needs work

I don't think the right answer is to check specifically for the existance of the Date module. Other modules can create their own types and they will have the same problems. Instead, we need to find a more generic way to check for values that might have been added by other modules. I'm not sure at the moment what that would be, but I am 90% sure this patch isn't going to get accepted if it contains a specific fix for the Date module without trying to solve the bigger issue.

Ken Ficara’s picture

The last post makes a very good point about these two patches, neither of which seem to have been tested. What's going on with this issue?

aisamat’s picture

I've this error too... when will you patch the official module?

colan’s picture

@KarenS: Has the capitalization been fixed in the Date module, or are you still waiting for someone to test this?

As for the other problem, I think Schema should provide an API function that contrib modules can use to register their non-core types. How does that sound as a solution?

KarenS’s picture

I changed capitalization in the date module months ago. There are still errors being reported by Schema. I don't know how to solve it from here and I don't really care which way it gets fixed.

colan’s picture

Thanks.

Foliks: Please provide feedback on my idea above, or suggest something better.

pobster’s picture

The warning errors are minor and can be hidden by setting a variable in schema module.

http://drupal.org/node/1237974#comment-4942554

Pobster

davew1970’s picture

Hmm.

I'm experiencing this problem too.

For me it is absolutely critical that this gets fixed.

I'm looking to install at least 6 sites that access data from tables created and regularly updated by other software. Many of those tables contain columns of type 'datetime'.

It is not possible to alter the tables in any way.

I'm using Schema and Data to get the tables into Drupal and then using Views to display the content. The problem is that Views is totally destroyed (white screen of death) by the lack of support for this field type.

Surely the core team implemented a method of declaring database column base types that are not included in the core before removing any previously supported types. That would make it possible to extend core by means of a module that adds support for the data base type.

Now I'm willing to help fix this in any way I can but I'm new to Drupal and by no means am I a PHP expert so I'm going to need pointers.

So to recap the cause of the problem. Please correct me where I'm wrong.

The data base column type 'datetime' is not supported by the core database API.
The Date module doesn't add support for the column type 'datetime' to the database API.
Schema doesn't add support for the column type to the database API but would support it if it were there.
The Data module relies on Schema to handle this.
Views explodes when it encounters this field type because there is no handler for it.

So what is needed is a module that extends the database API to support all the MySQL column types and exposes them correctly to all other modules.
Surely there is a way to do this. It would be amazingly short sited of the core team to not allow for this. Supporting other databases will inevitably result in similar situations for other column types specific to those databases since supporting other databases will encourage the import of data from other applications.

colan’s picture

Priority: Critical » Major

This is definitely not critical, as the module works fine with the warnings.

@davew1970: See my recommendation in #29.

davew1970’s picture

@colan, @KarenS.
Hi guys,
I'm wanting to fix this. Not specifically the Schema module perhaps but more specifically the whole MySQL datetime issue.
I've been looking at this for several days now and I keep takings half a step forward and then get stuck for a day or so.
I think I'm missing something in how this all fits together or I'm looking at it from a different angle than everyone else.
It seems to me that you two are the experts in this and can provide my missing link. Once I've got that I'm more than happy to prepare patches to sort this out.

Is there a forum or bulletin board type thing where we can discuss this, an issue queue feels like the wrong place.

colan’s picture

@davew1970: I'm afraid I haven't looked into it too deeply (even though I just took over as maintainer). You're probably much further ahead than me at this point! :)

davew1970’s picture

@colan: I've been looking further into this.
The patch in #24 is almost there. I agree, it shouldn't be specific to the Date module, it should be specific to the MySQL engine.

I've changed my mind a little on some of this.
In this case I don't think its appropriate for Date or any other module to be adding the 'datetime' type. It is a type provided by the database engine and should be supported from the lowest level however, as noted in #10, it isn't and the discussion referenced there gives sound reasons why it isn't even though the use of the word portable could use some clarity.

To clarify my point I am looking at this from the position that there is a table containing a 'datetime' that must be used 'as is' without alteration as opposed to a table created by Drupal.

Given that the core isn't going to add the type back in I think Schema should extend the core schema to allow other modules to recognise the existence of such columns in the database.

I've read somewhere that Date is moving into core so Date can't rely on Schema anyway so no help for @KarenS I'm afraid unless I'm missing something there.

So to clarify:
The patch in #24 needs to be not Date specific but MySQL specific
The type should only be available if the current engine is mysql.
In keeping with the drupal way, creation of tables containing that type should be discouraged (though I'm not convinced the drupal way is right).

I'll work on this a little more and see if I can create a patch.

davew1970’s picture

Status: Needs work » Needs review
FileSize
1.44 KB

Here is a patch that extends the schema types to add support for MySQL datetime.

It is only specific to the mysql engine.

It works on my system in as far as it stops the warning messages.

I think it should be extended to cover all the types not specified by core.

davew1970’s picture

Ooops, Sorry, ignore previous patch.

I forgot to add the bit for postgres engine since the change alters the structure of the class.

Here is a corrected patch

philosurfer’s picture

#39 works.

:-)P

moltra’s picture

Not sure if this is the same issue here, but I applied Patch from #39 and most of my datetime errors are hidden, but not the following.

no type for Schema type timestamp:normal.

dave bruns’s picture

#39 worked well for me, too. Thanks!

bryancasler’s picture

I can no longer test to respond to this, so that will have to be up to the community.

John Pitcairn’s picture

#39 works here.

bdone’s picture

#39 works. manually tested with following steps:

* clean D7 install
* drush dl schema date
* drush en schema date date_api -y
* add a date field (machine name: field_date) to any content type
* note the following schema error: drush schema-compare extra

Field field_data_field_date.field_date_value: no Schema type for mysql type datetime.                                                                                                                                                                                               [warning]
Field field_revision_field_date.field_date_value: no Schema type for mysql type datetime.                                                                                                                                                                                           [warning]
field_data_field_date.field_date_value: no  type for Schema type datetime:normal.                                                                                                                                                                                                   [warning]
Field field_data_field_date.field_date_value: no Schema type for  type datetime.                                                                                                                                                                                                    [warning]
field_revision_field_date.field_date_value: no  type for Schema type datetime:normal.                                                                                                                                                                                               [warning]
Field field_revision_field_date.field_date_value: no Schema type for  type datetime. 

* applied patch #39
* note schema errors are removed: drush schema-compare extra

LTech’s picture

#39 worked for me

dankoB’s picture

I applied the patch to 7.x-1.0-beta4. Got a Fatal error after running cron:
Fatal error: Call to undefined method SchemaDatabaseSchema_mysql::schema_field_type_map() in ... /sites/all/modules/schema/schema.module on line 189
Had to go back to unpatched. Should I have applied the patch to a different version?

FYI, this may be unrelated, but in addition to the datetime errors I have these errors without the patch:

The Schema comparison report shows:
    52 modules with matching tables
    3 extra tables
    2 modules with mis-matching tables

Not sure how to assess those. Followed the link to structure/schema/compare but don't see any comparison report chart here, just the regular Structure menu.

7ueryuha34r8’s picture

Version: 7.x-1.x-dev » 7.x-1.0-beta4
FileSize
3.22 KB

My first attempt to help the community, hope you all like it.

This patch is intened to provide consistent type mappings by overriding getFieldTypeMap() and adding any missing contributed module types to the list. Lemme know if this works out.
Tested with MySQL only. In theory, it should work with any db engine that Schema supports (mysql and pgsql at the moment).
Also tested it with the Date module as it's the only one I know of that provides its own custom db type (datetime). Would love to know what other modules provide their own custom types that aren't in core and works with this patch.

Patched against 7.x-1.0-beta4 (should work for 7.x-1.x-dev, too)

deepbluesolutions’s picture

this patch worked a treat against the dev version of schema, clearing all datetime issues from the compare screen.
Ive still got an issue with disable_breadcrumbs, which ill log over there, as im thinking thats where it needs to be

disable_breadcrumbs.nid is part of the primary key but is not specified to be 'not null'.

but your patch cleaned up all those datetime issues, well. many thanks.

Dave Reid’s picture

Version: 7.x-1.0-beta4 » 7.x-1.x-dev

Marked #1211294: Various bogus errors from Schema compare as a duplicate of this issue.

Status: Needs review » Needs work

The last submitted patch, schema-support-custom-types-1237974-48.patch, failed testing.

Dave Reid’s picture

mkesper’s picture

Where to set that variable exactly? This is annoying...

WhiplashInfo’s picture

Version: 7.x-1.x-dev » 7.x-1.0-rc1

After I used the Patch module to run both "schedule-support-datetime-1237974-39.patch" and "-48" patches I still have the same error:
---------
Field drup_field_data_field_date.field_date_value: no Schema type for mysql type datetime.
Field drup_field_data_field_date.field_date_value2: no Schema type for mysql type datetime.
Field drup_field_revision_field_date.field_date_value: no Schema type for mysql type datetime.
Field drup_field_revision_field_date.field_date_value2: no Schema type for mysql type datetime.
field_data_field_date.field_date_value: no type for Schema type datetime: normal.
Field field_data_field_date.field_date_value: no Schema type for type datetime.
field_data_field_date.field_date_value2: no type for Schema type datetime: normal.
Field field_data_field_date.field_date_value2: no Schema type for type datetime.
field_revision_field_date.field_date_value: no type for Schema type datetime: normal.
Field field_revision_field_date.field_date_value: no Schema type for type datetime.
field_revision_field_date.field_date_value2: no type for Schema type datetime: normal.
Field field_revision_field_date.field_date_value2: no Schema type for type datetime.
-----------
Database schema Inconsistent
The diagram shows the comparison report:
67 modules with matching tables
4 extra tables
2 modules with mis-matching tables
You should follow the instructions under Database updates now or run the database schema comparison report for more details.
OK
Database system MySQL, MariaDB, or equivalent
OK
Database system version 5.5.29-0ubuntu0.12.04.2-log
Error
Database updates Out of date
Some modules have database schema updates to install. You should run the database update script Immediately.
-----------
Thanks / Tomas

imclean’s picture

Version: 7.x-1.0-rc1 » 7.x-1.x-dev

#48 @zerocool2000, please remove whitespaces from blank lines and patch against git.

mmartinov’s picture

Status: Needs work » Needs review
FileSize
3.18 KB

Fixed the coding standard issues in the patch from #48

It is removing the errors for me, looks like it's working.

Yorgg’s picture

#56 worked for me

Peter Bowey’s picture

Thanks @mmartinov, the patch at #56 worked fine.

colan’s picture

Status: Needs review » Needs work

Thanks for working on this.

The code for each of those DB override functions looks nearly identical. To reduce duplication, maybe they could each call a common function which takes the DB as a parameter?

Also, some of the comments aren't capitalized or end with a ".".

mrded’s picture

I've changed code to Drupal standards. Also I think what we should not reduce duplication, and keep code separate. Because if we need to change for one of drivers - it can make some problems.

Please, check out my changes.

Dave Reid’s picture

Actually I think there's a better way to implement this, as a hook. I've tested this and it resolves the issues with Date fields schema warnings.

bdone’s picture

#61 works nicely. just need to remove this debug msg...

+++ b/schema.module
@@ -609,3 +609,40 @@ function schema_compare_table($ref, $inspect = NULL) {
+        dpm($col);
bdone’s picture

removed the dpm()

Dave Reid’s picture

Status: Needs review » Fixed

Committed to 7.x-1.x.

  • Commit 3b38f32 on 7.x-1.x by Dave Reid:
    Issue #1237974 by davew1970, bdone, mrded, Dave Reid, mmartinov,...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Sixpiece’s picture

Hello everyone! I'm new to Drupal, and was just wondering how to implement these changes. Is there a tutorial out there for this. Or could someone please explain this to me. I would be forever grateful.

Dave Reid’s picture

@Sixpiece Update to the latest module version. That's it.

msizec’s picture

got the latest version (1.2) and still having this error msg

mbehensky’s picture

I just encountered this issue as well. I have a new drupal installation, fully updated. My Schema module is 7.x.1.2. I have a table I'm trying to look at with a 'datetime' field. When I go to Structure->Data Tables->Adopt tables I get the following warning at the top of the page:

User warning: solar_data.time: no schema type for mysql type datetime. in schema_schema_type() (line 384 of /etc/drupal/sites/all/modules/schema/schema.module).

If I adopt the table anyway, I get the same error twice again.

If I then go to View Records->View nothing happens (there are plenty of records in the table). I am assuming this is because of this datetime problem.

Maybe there has been a regression? I am thinking of trying one of the patches, but if they are already applied in the current version this would be pointless. I am a drupal novice, so maybe I'm doing something else wrong, and the warnings are benign.

Update:

My problem (can't view records) probably isn't related to the datetime warning. I copied the solar_data table to another table and changed the type of my "time" field to a fixed length char. I then adopted that new table (without warnings for that table; I still get the warnings for the original table). I couldn't view the records on that table either. I'm going to investigate further.

Thanks for looking into this.

leolandotan’s picture

Hi guys, I'm also gettings the same error

User warning: webform_views_request_invite.submitted: no schema type for mysql type datetime. in schema_schema_type() (line 384 of /var/www/html/drupal/sites/all/modules/schema/schema.module).

in combination of the ff. modules: schema (7.x-1.2), data (7.x-1.0-alpha7), webform_mysql_views (7.x-1.1) and webform (7.x-4.2).

I just have a webform that accepts first and last name, email and gender.

wOOge’s picture

I'm getting this error as well now — using DEV version (Dated March 2014)

imclean’s picture

Some modules may declare a fields as datetime, such as Entity Registration. See: #2310039: Numerous Schema Errors + User warning: registration_entity.reminder_date: no type for schema type :normal

However the Date module won't necessarily use a datetime field to store the date. For example, if it's an ISO date field then the field will be varchar.

These modules probably shouldn't be specifying database specific fields in the first place.

imclean’s picture

Then again, it seems correct: https://www.drupal.org/node/146939

The hook introduced by this patch doesn't actually add datetime, although it provides an example of how to do it in schema.api.php.

TD44’s picture

I'm still having User warning : construction.spawned_at: no schema type for mysql type datetime. in schema_schema_type() (line 384 in /var/www/gamingproject/sites/all/modules/schema/schema.module).

When i try to use external tables with Data module, the columns of date type are always empty.

Can someone with high skill in programming help to fix this error?