Zikula Community

• **unknown user**
  
  

  • Rank: Registered User
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 29

  Posted: Sep 18, 2006 - 02:18 PM

  Why do we store table information in pntables and not in a seperate database. I think this would be much more comfortable especially together with the use of DButil.
  Whenever you want to create a table change the table structure, you also need to change pntables. This is very annoying. If the database structure were stored in a database it would be easily possible to change database structures with one command.
  
  All this would not be necessary if we would store everything in a database. I think that a module programmer should not need to worry about keeping table information up to date. Instead, I think that this should be handled automatically internally by DBUtil.
  
  This would be much more convenient for module developers. For example at the moment when writing a module you would need to write first pninit.php and then again pntables.php. If table information were handled by DBUtil you would not need to write pntables.php any more.
  

  • 
  •  
• rgasch
  
  

  • Rank: Team Member
  • Registered: Jan 05, 2003
  • Last visit: May 28, 2010
  • Posts: 775

  Posted: Sep 18, 2006 - 11:10 PM

  Quote

  If the database structure were stored in a database it would be easily possible to change database structures with one command.

  
  Yes, but it would be slower because in order for your application to then know the DB structure, you'd have to do another select. And for every pnModLoad() you'd have to do yet another select. Reading the stuff from file is much simpler and easier.
  
  

  Quote

  For example at the moment when writing a module you would need to write first pninit.php and then again pntables.php. If table information were handled by DBUtil you would not need to write pntables.php any more.

  
  I guess in theory this could work but speaking for myself, I'm quite happy with the current pntables.php files.
  
  One other thing you should know is that in 0.8 the information in pntables will/can contain some extra entries other than the table/column ones. This information is used to enable and/or configure certain automatic functionality and would thus further comlicate any effort to move such information to the DB.
  
  Greetings
  R
  
  

  • 
  •  
• **unknown user**
  
  

  • Rank: Registered User
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 29

  Posted: Sep 19, 2006 - 02:28 AM

  Thank you for your reply. I understand your point that moving pntables to the database might slowdown postnuke. Of course we all want to keep postnuke fast, and reduce DB access as much as we can.
  
  But as it is now DB structure handling with DBUtil is quite complicated. I am currently working on a module where users (with appropriate permissions) should be able to create tables and define their own table structure. In such a case it is difficult to use the current pntables system where database structure definitions are hardcoded in pntables.php.
  
  Another point is that with the current system (current cvs PN 0.8 17.8.06), you can not just write:
  DBUtil::createTable($mytablename, $SQL)
  to create a table. This will not work.
  If you want to create a table with DBUtil the table must first be registered in pntables.php before you can actually create the table using DBUtil.
  
  I think that if I write DBUtil::createTable($mytablename, $SQL) this should be sufficient information for the system to know that I want to create a new table. After using this command, it should be the job of the system to perform all needed operations to create a new table. At the moment the system, does only do the desired operations if the new table is already registered through pntables. This is difficult to do, if you write a module that allows users to create a table and allow them to choose freely the name of a table.

  • 
  •  
• rgasch
  
  

  • Rank: Team Member
  • Registered: Jan 05, 2003
  • Last visit: May 28, 2010
  • Posts: 775

  Posted: Sep 19, 2006 - 10:57 PM

  Quote

  But as it is now DB structure handling with DBUtil is quite complicated. I am currently working on a module where users (with appropriate permissions) should be able to create tables and define their own table structure. In such a case it is difficult to use the current pntables system where database structure definitions are hardcoded in pntables.php.

  
  OK, I see your point. For doing this I would recommend that you create a fixed module table (ie: one that has an appropriate pntables.php entry) which then stores the data of your custom table definitions. The next step would then be to somehow merge this info dynamically into the pntables info, which might require a small core hack, so that you can then again use the easy DBUtil methods to manipulate your data.
  
  
  

  Quote

  Another point is that with the current system (current cvs PN 0.8 17.8.06), you can not just write:
  DBUtil::createTable($mytablename, $SQL)
  to create a table. This will not work.
  If you want to create a table with DBUtil the table must first be registered in pntables.php before you can actually create the table using DBUtil.

  
  If you have the valid SQL statement to create your table, just do a
  

  Code

  DBUtil::executeSQL($sql);

  
  and you should be fine.
  
  
  Greetings
  R

  • 
  •  
• markwest
  
  

  • Rank: Team Member
  • Registered: Mar 18, 2002
  • Last visit: Oct 21, 2009
  • Posts: 6606

  Posted: Sep 19, 2006 - 11:31 PM

  Following on from Robert's post your pntables file could call an API to get the details of the current defined tables thus integrating easily with the pntables setup.
  
  With regard to createTable this only uses pntables to form the SQL statement if the SQL parameter is empty thus if you supply an SQL parameter the method works the same as earlier SVN versions of the method.
  
  -Mark
  
  --
  Visit My homepage and Zikula themes.

  • 
  •  
• **unknown user**
  
  

  • Rank: Registered User
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 29

  Posted: Sep 20, 2006 - 02:09 AM

  Thank you all for your helpful comments and proposals!
  
  Rgashs proposal to use DBUtil::executeSQL($SQL); worked fine. I also tried to use DBUtil::createTable($mytablename, $SQL) in various ways, but I was not able to use this command without registering the table before.
  
  I used the code as it was written in the documentation:
  

  Code

  $sql = "id      I      NOTNULL AUTO PRIMARY,
              title   C(255) NOTNULL DEFAULT '',
              content C(255) NOTNULL DEFAULT '',
              online  L   NOTNULL DEFAULT 0";
  
      if (!DBUtil::createTable('ht_table1', $sql)) {
          pnSessionSetVar('errormsg', _CREATETABLEFAILED);
          return false;
      }

  
  
  This did not work. In order to work correctly I had to write:
  

  Code

  $GLOBALS['pntables']['ht_table1']= 'ht_table1';
  $sql = "id      I      NOTNULL AUTO PRIMARY,
              title   C(255) NOTNULL DEFAULT '',
              content C(255) NOTNULL DEFAULT '',
              online  L   NOTNULL DEFAULT 0";
  
      if (!DBUtil::createTable('ht_table1', $sql)) {
          pnSessionSetVar('errormsg', _CREATETABLEFAILED);
          return false;
      }

  
  
  I also managed to follow your proposals of creating a fixed module table which stores the data of your custom table definitions and to merge this info dynamically into the pntables info. Thank you for your advise. This works quite well. However, I still wonder, if this is the best way of handling these issues. Doing so the code becomes quite complicated considering the fact that these are quite basic operations. The only think I want to do is to create a table. This, I think, is quite a basic operation. Well, if my module were the only module that needed these kind of operations then of course it would be the best solution to put all necessary code for this into the code of the module. But since this is a quite a basic operation, I think this code will also be needed by other module developers. That is why I still think that it might be worth considering to move the code needed for these operations to the system level in order to further facilitate module programming. Anyway at least there is now a way for me to further develop my module, so thank you very much for your help!

  • 
  •  
•  
•  

Users on-line

• internetking

This list is based on users active over the last 60 minutes.