We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 23491 ☆ A M B ☆
    • 1,056 Posts
    I’ll see if I can make this quick:

    Let’s say I have 2 sites in respective databases: modx_mysite1 and modx_mysite2 (both running on the same dedicated server...)

    I need to develop a table that both sites can access (via snippet calls), and it is a table I’d prefer not to duplicate...

    So I put it in what we’ll call the modx_shared database.

    [*] Can the MODx dbAPI be leveraged to connect to this alternate database?

    If not, I assume I can use

    mysql_select_db( 'SHARED_DATABASE_NAME' );
    


    ...but I also imagine I’d need to change back to the site-specific db

    global $dbase;
    mysql_select_db( $dbase ); // Ensure original DB is selected once done
    


    Is there anything wrong with this approach? I guess one concern could be the complexity of the snippet itself:

    [*] Does the snippet reference any other snippets that are dependent on the original db connection, etc...


    I know I could simply create a secondary MySQL connection to the desired DB, and then end it, but I’m one who likes to know his options when available.

    Thoughts?

    EDIT: http://modxcms.com/dbapi.html revealed that db changing likely isn’t an option... Has anyone had a need like this before? Ideas for solutions?
      Mike Reid - www.pixelchutes.com
      MODx Ambassador / Contributor
      [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
      ________________________________
      Where every pixel matters.
      • 26435
      • 1,193 Posts
      The MODx DBAPI is a great convenience when you need to pull from or enter into the modx database. If that were the case (which in your example it clearly is not) I would strongly recommend using the DBAPI.

      In this instance, however, the DBAPI may well make things more complicated and it may be in your best interest (at this point in the MODx release (the future will change this)) to use php’s mysql functions to access the third/alternate database.

      I am sure within a few posts, OpenGeek will correct me as he tends to think many cycles ahead in the development of MODx than the rest of us here in the community.

      -sD-
      Dr. Scotty Delicious, Scientist
        Husband, Father, Brother, Son, Programmer, Atheist, Nurse, Friend, Lover, Fighter.
        All of the above... in no specific order.


        I send pointless little messages
        • 23491 ☆ A M B ☆
        • 1,056 Posts
        Thanks, Scotty!

        LoL ... I, too, am anxiously awaiting OG’s response, as I’m sure xPDO / new MODx core, etc. will handle this, as well as scratch-n-sniff via the monitor, natively.

        For a simple query from the shared db, do you see any issue with mysql_select_db versus establishing a second dbconnection?

        Testing as we speak...

          Mike Reid - www.pixelchutes.com
          MODx Ambassador / Contributor
          [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
          ________________________________
          Where every pixel matters.
          • 23491 ☆ A M B ☆
          • 1,056 Posts
          The Test Snippet:

          <?php
          global $dbase;
          
          mysql_select_db( 'modx_shared' );
          
          // Select statement to come...
          
          mysql_select_db( $dbase );
          
          return 'hello world';
          ?>
          


          The result

          « MODx Parse Error »
          MODx encountered the following error while attempting to parse the requested resource:
          « Execution of a query to the database failed - Table 'modx_shared.modx_site_templates' doesn't exist »
          


          That bites... not sure why (haven’t explored in the core), but simply selecting an alternate db causes the crash...

          Trying to "reselect" the same db crashes nothing (as expected) - unfortunately, it is useless smiley


          <?php
          global $dbase;
          
          // mysql_select_db( 'modx_shared' ); // Look what you did, you little jerk
          
          // Select statement to come...
          
          mysql_select_db( $dbase );
          
          return 'hello world';
          ?>
          



          ...looking deeper into the dbAPI (deeper than the MODx site dbAPI docs, that is) there is indeed a connect method that might be able to be leveraged... EDIT: Didn’t have much luck here, either... read solution below

          <?php
          // ...
          
             function connect($host = '', $dbase = '', $uid = '', $pwd = '', $persist = 0) {
                global $modx;
                $uid = $uid ? $uid : $this->config['user'];
                $pwd = $pwd ? $pwd : $this->config['pass'];
                $host = $host ? $host : $this->config['host'];
                $dbase = $dbase ? $dbase : $this->config['dbase'];
          
          // ...
          ?>
          



          SOLUTION!

          You can count on me to sometimes over complicate things...

          So, you want to use the dbAPI and an alternate db? As long as the same db user is authenticated on both DBs, simply prefix the table with the db-of-your-choice and you’re good to go smiley (duh)

           $myQueryResult =  $modx->db->select( '*', 'modx_shared.test_table' );
          
            Mike Reid - www.pixelchutes.com
            MODx Ambassador / Contributor
            [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
            ________________________________
            Where every pixel matters.
            • 22303 MODX Staff
            • 10,725 Posts
            The problem is that since you are trying to access two db’s on the same request, you must maintain separate connections to the databases if you are going use the mysql_select_db function. Once you run that command, the connection used by all mysql_query() calls is set to that database, unless specifically passed a connection resource.

            What you need is a new instance of the DBAPI class, which maintains it’s own connection to the other mysql database...
            $mydb= new DBAPI('localhost', 'shareddb', 'user', 'pwd');

            Then call the same functions you would from the $modx->db object.
            $mydb->select( '*', 'test_table');


            If it’s a bunch of shared data though, you could skip that, and download xPDO from SVN and use it to connect to your other database, get instant object-oriented PHP scaffolding for your tables, and become familiar with the future of MODx and database access, all at the same time. laugh Of course, I may be biased and just trying to get some testing assistance on my new object-oriented database access layer. tongue
              • 23491 ☆ A M B ☆
              • 1,056 Posts
              Quote from: OpenGeek at Jan 04, 2007, 07:08 PM

              What you need is a new instance of the DBAPI class, which maintains it’s own connection to the other mysql database...
              $mydb= new DBAPI('localhost', 'shareddb', 'user', 'pwd');

              Then call the same functions you would from the $modx->db object.
              $mydb->select( '*', 'test_table');


              What’s funny is that I was actually thinking that I’d have to create a separate (new) instance of DBAPI on my way in to work this morning. Glad to see a few possible solutions for implementation.

              Quote from: OpenGeek at Jan 04, 2007, 07:08 PM

              If it’s a bunch of shared data though, you could skip that, and download xPDO from SVN and use it to connect to your other database, get instant object-oriented PHP scaffolding for your tables, and become familiar with the future of MODx and database access, all at the same time. laugh Of course, I may be biased and just trying to get some testing assistance on my new object-oriented database access layer. tongue

              The time for me to learn xPDO is now and I’ve love to begin a bit of user testing, etc. Where is the best place (somewhere within the xPDO site, I assume) to start so that I may implement into MODx and begin testing? Any other immediate benefits an xPDO approach may offer?
                Mike Reid - www.pixelchutes.com
                MODx Ambassador / Contributor
                [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
                ________________________________
                Where every pixel matters.
                • 22303 MODX Staff
                • 10,725 Posts
                Quote from: pixelchutes at Jan 05, 2007, 09:18 AM

                The time for me to learn xPDO is now and I’ve love to begin a bit of user testing, etc. Where is the best place (somewhere within the xPDO site, I assume) to start so that I may implement into MODx and begin testing? Any other immediate benefits an xPDO approach may offer?
                I’m preparing xPDO 1.0-beta for download from the xPDO site, hopefully sometime later today, in preparation to start sharing some MODx components and example solutions I’ve been working on via xPDO for the past few months.

                If you are using PHP 5.1+, xPDO has the benefit of using PDO directly, which is a compiled extension for database access that is performing faster than the native mysql driver in many cases. PDO has some benefits of it’s own, including making use of prepared statements (which MySQL can precompile and optimize on that side for even better performance, and which also takes care of thwarting any SQL injection attacks), the ability to access any database platform via a single, unified API/access layer, and there are many more.

                Also note that current documentation is still sparse and a little dated, but I am also working to have new API docs, tutorial docs, and examples up on the xPDO site this weekend.

                Actually, I suggest waiting the weekend before downloading xPDO. I’m in the process of moving the xPDO project to a new SVN server and I should have that all straightened out come Monday. I’ll make followup announcements at that time with details on how to get your hands on it...
                  • 23491 ☆ A M B ☆
                  • 1,056 Posts
                  Fantastic news! And for the record, xPDO had me at "Hello."
                    Mike Reid - www.pixelchutes.com
                    MODx Ambassador / Contributor
                    [Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
                    ________________________________
                    Where every pixel matters.
                    • 24719
                    • 194 Posts
                    wow. i think i understand xpdo now and it looks amazing. nice work jason.

                    how stable is the current release (1.0a13)? is it good enough for production use?

                    keep it up mate wink
                      • 22303 MODX Staff
                      • 10,725 Posts
                      Quote from: redman at Jan 20, 2007, 10:29 AM

                      wow. i think i understand xpdo now and it looks amazing. nice work jason.

                      how stable is the current release (1.0a13)? is it good enough for production use?

                      keep it up mate wink
                      Thanks for the props. I need some help getting it documented, too, so I hope a few more people start to explore and understand it.

                      And well, anything being ready for production use is relative IMHO. I’ve been using various versions of xPDO for production sites since last summer. Now, that’s not to say there aren’t bugs, but it’s powering some critical client sites of mine and generally making my life a breeze when adding functionality to those sites, so my answer would have to finally be, yes, it is stable enough for production use. And since I do depend on it working to support my sites and projects, and because it’s open source, you should rest comfortable knowing when you do find bugs, if I don’t fix em (which I of course would), anyone with the skills to can.

                      I do have some new features and bug fixes coming this weekend, but feel free to dive in. In fact, I’m going to set-up a forum dedicated to xPDO today, and have already created an IRC channel on freenode for it: #xpdo.