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:

http://pseudo-flaw.net/content/tftpgrab/

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:

http://pseudo-flaw.net/content/tftpgrab/

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.