Why is Block table delta field only 32 chars?
I spent a good long while trying to figure out why my 38 char delta block would show up in the admin_display but would not get assigned to a region. I realized that UPDATE ... WHERE delta= "full 38 chars" was not going to find my truncated entry created by _block_rehash :( Is there a reason to limit the length of this field? Should I submit a patch to check for this in _block_rehash and alert the user? Best, Jacob
Actually, most modules use a short integer starting for the deltas, so varchar(32) is awfully big for this. The question is rather: why is it actually a vc32 if all examples in core and docs use integer deltas. ----- Original Message ----- From: "Jacob Singh" <jacob@civicactions.com> To: <development@drupal.org> Cc: <ca-dev@lists.civicactions.net> Sent: Tuesday, August 28, 2007 8:49 AM Subject: [development] Why is Block table delta field only 32 chars?
I spent a good long while trying to figure out why my 38 char delta block would show up in the admin_display but would not get assigned to a region. I realized that UPDATE ... WHERE delta= "full 38 chars" was not going to find my truncated entry created by _block_rehash :(
Is there a reason to limit the length of this field?
Should I submit a patch to check for this in _block_rehash and alert the user?
Best, Jacob
I totally prefer string based deltas. It's much more maintainable and has no real overhead. Here is my typical module_block: case "list" $blocks['list_of_nice_users']['info'] = "Nice Users List" break; case 'view': $function_name = '_mymodule_blocks_' . $delta; if ( function_exists( $function_name) ) { return $function_name(); } break; then I have all my functions named nicely, plus I then can just create a template file called: block-mymodule-list_of_nice_users.tpl.php which makes it much easier to work with themers and other jr. developers than having files like block-mymodule-3.tpl.php (wtf is that?). I don't see how increasing this would impact performance at all. Best, Jacob On Tuesday 28 August 2007 00:27, FGM wrote:
Actually, most modules use a short integer starting for the deltas, so varchar(32) is awfully big for this.
The question is rather: why is it actually a vc32 if all examples in core and docs use integer deltas.
----- Original Message ----- From: "Jacob Singh" <jacob@civicactions.com> To: <development@drupal.org> Cc: <ca-dev@lists.civicactions.net> Sent: Tuesday, August 28, 2007 8:49 AM Subject: [development] Why is Block table delta field only 32 chars?
I spent a good long while trying to figure out why my 38 char delta block would show up in the admin_display but would not get assigned to a region.
I
realized that UPDATE ... WHERE delta= "full 38 chars" was not going to
find
my truncated entry created by _block_rehash :(
Is there a reason to limit the length of this field?
Should I submit a patch to check for this in _block_rehash and alert the
user?
Best, Jacob
On 28.08.2007, at 09:35, Jacob Singh wrote:
I totally prefer string based deltas. It's much more maintainable and has no real overhead.
Absolutely. We should change the delta (what does a block ID have to do with "delta" anyway?) to strings in D7. This would also pave the way for a hook_block_alter and other nice improvements for the block system. Konstantin Käfer — http://kkaefer.com/
Absolutely. We should change the delta (what does a block ID have to do with "delta" anyway?) to strings in D7. This would also pave the way for a hook_block_alter and other nice improvements for the block system.
and if it allows to have human readable css, this would be even nicer
Konstantin Käfer — http://kkaefer.com/
Well, it is 32 chars now - if you want it longer (e.g. 64) please roll the update patch ASAP. For the new menu system the deltas will be the menu names - so you CSS ID may be like "block-menu-mymenuname" -Peter On 8/29/07, Philippe Jadin <philippe.jadin@gmail.com> wrote:
Absolutely. We should change the delta (what does a block ID have to do with "delta" anyway?) to strings in D7. This would also pave the way for a hook_block_alter and other nice improvements for the block system.
and if it allows to have human readable css, this would be even nicer
Konstantin Käfer — http://kkaefer.com/
participants (5)
-
FGM -
Jacob Singh -
Konstantin Käfer -
Peter Wolanin -
Philippe Jadin