Forum: Ruby dynamic evaluation from a database

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Allan P. (Guest)
on 2008-10-13 04:16
Hi,

I am writing some functional testing applications in watir and I am most
likely going to have this application store the data in a MySQL or
Oracle database.  Since the tests are going to be in a constant state of
change I figure it might be best to store the scripts in the DB as well,
since this would allow me to re-deploy any code changes by updating the
clobs in the DB.

The are several ways to go about this, but was curious as to writing
stubs that just fetch the source directly from the DB using DBI to
evaluate it. In a general sense is this asking for too much trouble in
debugging or using require  etc ?  I assume require can be overloaded to
search the DB as well as the filesystem.
Robert K. (Guest)
on 2008-10-13 12:39
(Received via mailing list)
2008/10/13 Allan P. <removed_email_address@domain.invalid>:
> I am writing some functional testing applications in watir and I am most
> likely going to have this application store the data in a MySQL or
> Oracle database.

What is the reason for this?  What else data is there that needs to be
in sync with your test code?

>  Since the tests are going to be in a constant state of
> change I figure it might be best to store the scripts in the DB as well,
> since this would allow me to re-deploy any code changes by updating the
> clobs in the DB.

What do you mean by redeploy?  Are you doing the tests on multiple
systems?

> The are several ways to go about this, but was curious as to writing
> stubs that just fetch the source directly from the DB using DBI to
> evaluate it. In a general sense is this asking for too much trouble in
> debugging or using require  etc ?  I assume require can be overloaded to
> search the DB as well as the filesystem.

I'd rather not change the default require's functionality but instead
write a db_require or such which can be used for your special case.
This will also avoid any conflicts when there are similarly named
modules in your test suite and other load path.  My 0.02 EUR.

Kind regards

robert
This topic is locked and can not be replied to.