Non Database

Hi,

I am looking at using Ruby in an application that, as well as having the usual database will also need to interface to real-time data using tftp.

Is it possible to do this within RoR?

Where do I start?

Thanks

Adrian

Hi,

I am looking at using Ruby in an application that, as well as having the usual database will also need to interface to real-time data using tftp.

Is it possible to do this within RoR?

I don't see why not

Where do I start?

What is it that you do not know how to do?

Colin

I'm new to RoR. Would I need to be looking at the Model code to talk to the real-time stuff or would I need to look deeper into ROR? Just after some general pointers at this point. Need to spend some time working through some of the tutorials.

Thanks Adrian

Hi Adrian,

Have a look at this for some (Ruby) code ideas:

After that, it depends what your data looks like, and what you need to do with it.

Matt.

Thank you Matt and Colin, both a great help.

Adrian

Hi Adrian,

Have a look at this for some (Ruby) code ideas:

After that, it depends what your data looks like, and what you need to do with it.

Matt.

I'm new to RoR. Would I need to be looking at the Model code to talk to the real-time stuff or would I need to look deeper into ROR? Just after some general pointers at this point. Need to spend some time working through some of the tutorials.

I guess you would likely want to provide a model (not derived from ActiveRecord) to wrap the real time data access.

Further to this, much will depend on what you mean by 'real-time stuff'. If, when the user updates a page, it needs to display the absolutely up to date data then you may have to fetch it in-line during the rails action (via the wrapping model) and accept the performance hit this will cause. If, however, it is ok for the data to be at least a reasonable number of seconds old then you have the option of buffering the data locally (since you talk about using tftp I presume it resides on a remote machine). One option here may be to save it to the database routinely using a background task running at whatever rate is appropriate for your data. You could either add new records if you want to keep the history, or just update a single record table if not. The great advantage then is that as far as the rails app is concerned it is just accessing the database and your 'real time' mapping model is just a normal ActiveRecord derived one.

I use a variant of this approach for my weather station app. I have a local PC fetching data from my weather station every minute or two. It puts this into a file and pushes it to my remote hosted website server. It then uses ssh to run a rake task on the server to update the database, adding new records as I wish to display the history of course. The rails app then accesses the data without concern for the fact that it is real time.

Colin

There's also this: http://rubyforge.org/projects/net-tftp/ which I originally ignored as it's /old/ but the code looks quite clean.

HI Colin,

What might a model not derived from ActiveRecord look like, and what's the advantage of doing that? I'm looking up data from a 3rd party API, but somply have the code in the controller, without a model.

Tnx, Matt.

HI Colin,

What might a model not derived from ActiveRecord look like, and what's the advantage of doing that? I'm looking up data from a 3rd party API, but somply have the code in the controller, without a model.

It looks exactly like an ActiveRecord model except that it starts class MyModel instead of class MyModel < ActiveRecord::Base and of course it does not have access to the ActiveRecord methods (find, etc).

The reason for putting the access code in a model rather than in the controller or controllers is to encapsulate it all in one place and to provide a nice interface for accessing the data. The model can then provide methods for fetching the data for example, and have attributes for the current values. The calling code can then use these methods and attributes without having to worry about how the tftp magic is done. This strategy also allows tests to be written to test the model independent of the controller code.

Colin

Okay thanks, going to try that.

Matt.