If the primary/desired way of finding and accessing data is through views,
the added overhead of integrating with the drupal search may not be
desired. I am all for keeping the code simpler as well. Drupal Search is
really not fast enough for large sites or searching through large amount of
data. For that Apache Solar would be suited better, but is another can of
worms in terms of setup and maintenance. There is also a google appliance
from Google, that has very low setup and maintenance needs, but costs money.
Another point that is related, we could create a webservice to run queries
against chado db on the dedicated prod or dev server, to alleviate the
requirements of a local dev environment. Such a webservice could also be
turned off on production. The difference would be that while loading pages
or dealing with data from the remote db, the pages will load slower in the
In turn we could have a large chado db of the different sites to be run
from the same database. And have a dev copy of said db with laxer
privileges, for devs working either on the server remotely or localy on
their dev environment and fetching data from those large databases. I do
not know if that is something of benefit to the projects themselves, but it
may improve how we do dev on tripal. Plus the data would be synced up
across all dev environments (if desired).
Those are my 2 cents :)
On Wed, Nov 9, 2011 at 11:15 AM, Chun-Huai Cheng <chunhuaicheng@...:
> Hi all,
> I'm glad Tripal is moving to Drupal.org!
> We had a discussion about the way Tripal creates Durpal nodes for the
> Chado data long time ago. As we're branching into Drupal 7, it might
> be a good time to revisit this issue.
> Right now we have a syncing mechanism to create Drupal nodes for all
> Chado features/organisms/analyses/stocks. I'm thinking maybe we can
> try getting rid of it and pull the data directly from Chado and create
> the node on the fly.
> We made the decision to sync data because we wanted to utilize
> Drupal's built-in search function. However, the built-in search is
> slow and wasn't very helpful for most of our projects. We had to
> create separate search functions that query the Chado database
> directly. The following are some pros and cons.
> 1. No duplicate data. Genomic data are only stored in Chado
> 2. Save time. No time-consuming syncing procedure.
> 3. Save space. The Drupal database will be much smaller and may run faster.
> 4. Easier code maintaining and developing for future modules.
> 1. Need a lot of effort to re-write code. (but we may need to do this
> for migrating into Drupal 7 anyway.)
> 2. Loss of the Drupal built-in search capability.
> Maybe we can try it as another branch? What do you guys think?
> On Tue, Nov 8, 2011 at 1:15 PM, Stephen Ficklin <spficklin@...>
> > Hi Tripal developers!
> > We have a new Drupal developer, Alex, at WSU who just started. He has
> > started some topics we've discussed in the past. For instance, when we
> > submitted the Tripal paper one of the reviewer comments was that we look
> > migrating Tripal over to be a module (Project) on the Drupal website.
> > now you can't find Tripal when you look through the Drupal module
> > repository. Some of the advantages for making this transition would be
> > we would get automatic notifications when new Tripal modules are
> > and also we can automate installation of Tripal modules and upgrades
> > Drush. This move would force us to follow the Drupal coding standards,
> > which we need to do.
> > So, here is a proposed plan put together by discussions with Alex and
> > and some input from Lacey too. Let me know what you think:
> > 1. We create two Drupal projects: a Tripal module project and a Tripal
> > Theme project.
> > 2. We abandon the SVN repository and switch to the Drupal git
> > 3. We change the organization of our directory structure in this way:
> > Tripal Project:
> > /sites/all/modules/tripal/base/tripal_<module_name> (for the core
> > modules)
> > /sites/all/modules/tripal/extensions/tripal_<extension_name> (for the
> > extension modules)
> > Tripal Theme Project:
> > /sites/all/themes/tripal_theme/base/ (for the Tripal base theme)
> > /sites/all/themes/tripal_theme/subthemes/<extension_name>_theme/ (for
> > Tripal extension sub themes)
> > 4. With this structure we have a single Tripal module and all of the
> > modules (i.e. tripal_feature, tripal_organism, etc.) become sub modules.
> > 5. We handle extension modules a bit differently. Extension modules get
> > put back into the Tripal as sub modules. But we store those in a
> > 'extensions' directory. When someone downloads Tripal they get everything
> > (base and extensions). We also create sub themes corresponding to each
> > extension sub modules.. These sub themes are part of the Tripal theme,
> > allow us to keep extension separate. The process for submitted
> > modules for inclusion in Tripal would be as follows. We will create a
> > testing suite using Jenkins
> > (https://wiki.jenkins-ci.org/display/JENKINS/Home) and Sellenum
> > (http://seleniumhq.org/) to ensure the extension modules don't conflict
> > the Tripal package. We expose this testing suite to developers to test
> > own modules. If the modules pass we can then include them in Tripal. We
> > can also maintain the description of extension modules on the Tripal
> > to ensure folks get credit where credit is due.
> > The first step in migrating to Drupal is to create a sandbox where we can
> > prepare the project for review. After review and acceptance then Tripal
> > becomes a full module on the Drupal site. After that we can then look at
> > branching to Drupal 7.
> > Any objections or concerns or other ideas?
> > Stephen
> > RSA(R) Conference 2012
> > Save $700 by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > _______________________________________________
> > Gmod-tripal-devel mailing list
> > Gmod-tripal-devel@...
> > https://lists.sourceforge.net/lists/listinfo/gmod-tripal-devel
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> Gmod-tripal-devel mailing list