Posted by zostay on April 29, 2007 at 12:19am
Jump to:
| Project: | Site tours with Amberjack |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I was going to write a block listing the available tours for my site and discovered that two different entity types are being stored in the same table. This works, but it makes it difficult to extend in the future and should be dealt with. The tables ought to be refactored into two separate tables, one for the pages and one for the tours.
If this were done, the description column would not have to be encoded using serialize, which makes it harder to customize.
I can probably make the changes and contribute a patch back, if you're interested.
Comments
#1
I would split the tables if there was a real need of this. So far I don't think there's some customization that might require a separate table for the tour itself. The tour might have new parameters, and they would be serialized anyway, no need to have a field for each parameter, in my opinion. Can you suggest any use case that requires two tables?
#2
The main case is the just the fact that creating a custom view that lists the name and description of the site tours requires the extra step of performing a call to
unserialize()to get the description.Another potential, is a suggestion I just thought of, which is to make the site tour pages use Drupal filters to render the text. If you have to store the filter's fid in a new column, which is then unused on the site tour records.
Personally, I'd just as soon completely avoid using
serialize()/unserialize()altogether unless I really don't know what the structure is going to be. Instead, I'd rather create new columns in the site tour table for each new option rather than using data serialization which get added by site_tour.install on upgrade.