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

On 8 July 2010 11:21, Adrian W. [email protected] wrote:

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

Adrian W. wrote:

I’m new to RoR. Would I need to be looking at the Model code to talk to
the
real-time stuff

Probably.

–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

On 8 July 2010 11:39, Adrian W. [email protected] wrote:

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.

Colin

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.

On 8 July 2010 16:30, Colin L. [email protected] wrote:

On 8 July 2010 11:39, Adrian W. [email protected] wrote:

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.

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.

On Jul 8, 11:21 am, “Adrian W.” [email protected] wrote:

Adrian


You received this message because you are subscribed to the Google
Groups
“Ruby on Rails: Talk” group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 9 July 2010 12:40, MattB [email protected] wrote:

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

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.

Okay thanks, going to try that.

Matt.