We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 13643
    • 44 Posts
    Tom:

    Sorry for this much-delayed reply. I believe that somehow my installation of MODx got corrupted, because I did a fresh install myself, and the issue disappeared. I did, however, uncover an unrelated issue with MSSQL that appears to be a genuine bug, as confirmed by ttyiav: http://tracker.modx.com/issues/9901#change-21625

    I was wondering about something you said earlier, regarding the use of chunks to access linked servers in MODx. What I'm trying to done (and have successfully done with a core hack) is to create create a custom object model (component), using xPDO schema files that point to the linked server tables. I'm accessing this model using modx->addPackage, so where would chunks come into play? It seems like this is too low-level for chunks, but perhaps we're talking about two different uses of linked servers?

    Thanks for all your helpful input!

    Zach
      • 39404
      • 175 Posts
      stalemate resolution associate Reply #12, 13 years, 4 months ago
      Quote from: javadecaf at May 04, 2013, 10:23 PM

      I was wondering about something you said earlier, regarding the use of chunks to access linked servers in MODx. What I'm trying to done (and have successfully done with a core hack) is to create create a custom object model (component), using xPDO schema files that point to the linked server tables. I'm accessing this model using modx->addPackage, so where would chunks come into play? It seems like this is too low-level for chunks, but perhaps we're talking about two different uses of linked servers?
      Zach

      Hi Zach,

      You seem to have a much better handle on xPDO than I do. Being someone who uses MODX to do application development for mostly intranet uses rather than public-facing websites, I ran into an issue that xPDO cannot consume views. Views serve an important purpose: they encapsulate logic in a consistent way. If I try to get around the view using xPDO, then my view no longer becomes a point of encapsulation and I have multiple versions of the truth for something. Remember that views in a database can serve multiple needs: any other application wishing to replicate this logic need only to go to the view.

      Another issue with xPDO: there are only MS SQL Server and MySQL versions. If I walk into a client site and they say that their transactional systems (which I need to read against) are in anything other than MySQL or MS SQL, I've hit a brick wall. For example, going over a list of clients I worked at, I can think of a few source systems which don't fit into this: Oracle, Teradata, Sybase, SAP, MEDITECH, etc. So, for me, xPDO won't work with what I'm trying to do. I also don't think that creating xPDO drivers for all of these makes sense.

      In cases where xPDO won't suit me, I get around it by creating chunks which have placeholders. For example:
      SELECT * FROM [[+schema]]`grip_temporary_report_xml` WHERE `grip_temporary_report_xml_id` = [[+gripTemporaryReportXMLId]]


      I would then save the chunk as something like getTempReportXMLMySQL for MySQL, getTempReportXMLMSSQL for MSSQL, getTempReportXMLTeradata for Teradata, etc. Then when I get the chunk, I append the database type (which is a constant set up).

      The way in which this applies to linked servers is that if you are referring to a linked server, your table information becomes longer (e.g. [PRODSERV].app.some_table) and this could be used in a chunk so that if the linked server ever changed (e.g. due to a server upgrade or disaster recovery), then it's just a matter of replacing the constant somewhere else.

      However, all in all, you're better off with using xPDO. As well, with real bugs, I know that the MODX team is dedicated to continue to provide fixes to SQL Server; the only issue is that they don't have a system to test on, so that's where we come in in terms of identifying bugs and helping to resolve. Awesome work with the analysis provided in the bug tracker.

      Regards,
      Tom
        • 13643
        • 44 Posts
        Thanks Tom - I appreciate the explanation. I can see where your cross-platform work would require a different sort of solution than what I'm using. The ultimate goal for my client is to transition his system away from legacy DBF files and into a full relational database, so we're using xPDO as a sort of bridge between the two. I have personally never worked with views, so that limitation probably won't affect me, but I'm glad to know about it anyhow. We'll try to keep reporting the bugs as we find them!

        Zach