Deprecated - Drupal core

Xoops has the ability to install sql tables for any module. Why doesn't Drupal have something similar? (and along the same lines, why no web-installer?)

Considering how powerful drupal is, it's surprising that these simpler functionalities are overlooked.

While looking through drupal and the API documentation (drupaldocs.org) to learn how to create my first module, I noticed a potential database issue. This only relates to sites that use database replication. And it only relates to executing a delete followed by an insert of the same primary key. At the moment it's very very rare this would ever occur but I thought I'd mention it for future-proofing.

There are generally two types of replication (that I know of): transaction-based and replicator-master. For transaction-based the transaction logs are passed around to each server and queries are guaranteed to execute in the order submitted by the application. For master-based replication all queries are sent to a master server, usually balanced across threads, and passed to each slave. The master will usually not guarantee the order of queries (as each query can be passed to any thread). So a delete followed by an insert may end up executing on another database server as an insert followed by a delete. The insert fails on a duplicate key and the delete runs. Some or all of the servers have then lost that record.

Dear all,
I noted that the "date created" field of the node table is an integer. But, how to interpret (or resolve) it into date and time. Any resource out there can guide me through this calculation? Thank you for advice.
Andrew

I've been experimenting with tab-based site menus, sort of like the contributed Navigation module from 4.4. A simple modification to Block.module added extra regions for blocks (so I can put "Site Menu" in the top header or just above the main content), and CSS does the rest. It's a simple patch, and has potential uses beyond simply adding a menu to the top of my content (such as developing blocks that are appropriate to a footer, for example).

However, I'm now stumbling on another loss of functionality (as compared to Naviagation.module): I can't hide menu items. Navigation allowed me to set permissions on certain menu items, which was nice (so that my "Admin" tab didn't show unless you were in the Editor group). I can't do that with the stock Menu module.

As I've been thinking about this, I'm wondering if adding a role field to the menu table is the right answer. Perhaps, as a menu is being built, the system should parse down through the menu tree. If a tree has no nodes that are viewable to a user, that portion of the tree is pruned right off the menu. This would have the effect of hiding menu items that aren't pertinent, while also simplifying administration by making the hiding automatic (you're only need to worry about hiding the node, the menu pointer gets hidden automagically).

Is anyone working on something like this? Is this even the right approach? I'd really like to see, as a user, all the needed menuing functionality in a single module, and not have to fight to get Navigation.module ported to 4.5. It'd just be nice to have it all in one place, without several competing menu systems (Menu, Navigation, Taxonomy, or whatever else) trying to accomplish the same goal...

If you have some spare time (and you're not working on a patch for HEAD), consider fixing some bugs filed against Drupal 4.5. I would like to roll a second maintenance release in a couple weeks. See you in the patch queue.

Wondering if this is already possible, I don't see how to do it at this moment using Drupal 4.5.1.

I need the option for node 'owners' to be able to edit or delete all comments connected to a node they own. All I can do so far is have comment 'owners' edit or delete their own comments via a 'administer comments' permission. I need node owners to be able to have control over 'their' node.