create_date in table content_props

[Wiedmann]

Hi,

from what I see, there will be nothing written to the column "create_date" in the table "content_props" if I add a new page/block. Is there a reason for this?

Regards,
Carsten

CMS Made Simple 1.2.4

[Wiedmann]

Some additional database questions:

"cms_content_props_seq":
IMHO in the column content_props_seq.id should be the highest number from content_props.content_id. That's not true in my installation. In all other seq tables that's the case, but not in content_props_seq.

creation from new tables:
What's the reason for "$taboptarray = array('mysql' => 'TYPE=MyISAM');" in "schema.php" or module installations? (Of course, with my setup this have no effect...)

"module_templates":
in the table "module_templates" you want have an index over 2 columns. Is this index necessary for you? Because this index can't be created on all installations, and your setup script have no knowledge about this situation (instead it writes: DONE and all success).

Regards,
Carsten

[calguy1000]

Hi,

from what I see, there will be nothing written to the column "create_date" in the table "content_props" if I add a new page/block. Is there a reason for this?

Regards,
Carsten

CMS Made Simple 1.2.4

Yes, you're correct from what I see, I think it was probably a bug introduced a while back or something.  The modified date works well, so it's probably a one line fix..... either way this is a minor bug.

[calguy1000]

Some additional database questions:

"cms_content_props_seq":
IMHO in the column content_props_seq.id should be the highest number from content_props.content_id. That's not true in my installation. In all other seq tables that's the case, but not in content_props_seq.
[/quote]
Yes, it should be the highest number from the content_props.content_id something must be a little messed up in your installation.  I've heard of this happening from time to time, but have never been able to find out what causes it.

creation from new tables:
What's the reason for "$taboptarray = array('mysql' => 'TYPE=MyISAM');" in "schema.php" or module installations? (Of course, with my setup this have no effect...)

If you look at the adodb data dictionary documentation, indicates that that is telling the databaase library what type of table to create.  I don't think adodb_lite supports this, and enforces only MyISAM, but the full adodb does.

"module_templates":
in the table "module_templates" you want have an index over 2 columns. Is this index necessary for you? Because this index can't be created on all installations, and your setup script have no knowledge about this situation (instead it writes: DONE and all success).

This seems to work fine for me:

Code: Select all

mysql> show create table cms_module_templates;
+----------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table                | Create Table                                                                                                                                                                                                                                                                                                               |
+----------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| cms_module_templates | CREATE TABLE `cms_module_templates` (
  `module_name` varchar(200) default NULL,
  `template_name` varchar(200) default NULL,
  `content` text,
  `create_date` datetime default NULL,
  `modified_date` datetime default NULL,
  KEY `module_name` (`module_name`,`template_name`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 |
+----------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.03 sec)

[Wiedmann]

Yes, it should be the highest number from the content_props.content_id something must be a little messed up in your installation.

This happens just after each fresh installatin with sample data.
- Insert two new pages
- Delete these new pages
- add a addititional
And now compare the id value. I can reproduce this every time.

Well, later (must go to shopping with my wife ...) I can look for a fix.

If you look at the adodb data dictionary documentation, indicates that that is telling the databaase library what type of table to create.

I know... adodb_lite supports this too. Let me ask in other words: Why want you have MyISAM? Add the moment this as also 2 other issues:
- you set this only for the mysql driver, but not for the mysqli driver
- you set this only for the "normal" tables, but not for the "seq". Result is a mix of both tables, if the default table type is "InnoDB" on the server.
and you don't use any FULLTEXT index. So it's save to use both table types and respect the user setting: default table type.

This seems to work fine for me:

For you... Well, not all people on the world are using latin1 as charset for the server. If someone is using utf8 as default charset the index can't be created, because the (resulting) index length is to long.

(Of course, your charset handling with utf8 aware databases is another topic...)

[Wiedmann]

Yes, it should be the highest number from the content_props.content_id something must be a little messed up in your installation.

Well, the fix is easy:
Just remove the table "content_props_seq" from the installation. It's not used.
--> content_props.content_id is allways set from content.content_id/content_seq.id, and so content_props_seq.id will never be updated.

Regards,
Carsten

[Wiedmann]

The modified date works well, so it's probably a one line fix.....

Well, after looking through the code (BTW: I love well documented code...):
You can't set the creation date. Thus it's better to remove this column.

Additional question:
What is the meaning of param1, param2  and param3 in this table ("content_props")?. They can't be used from what I see. IMHO it makes also no sense to set them to an empty string (just don't use them in the prepared statement.

It's also curious that there is just an update in the table "content", but in "additional_users" and "content" there is first a delete of the existing row and then an insert of a new row (while an update). Is this not unnecessary db transfer?