Integrate new fields in a table with CRUD functionality: simple question

Hi,

I've got an "expenses" table which I modified as follows:
added column "account_number"
renamed column "type" to "transaction_type"

Can I add CRUD for the columns with:
first: ruby script/generate model expense
then: ruby script/controller expense

Will all the existing CRUD for other columns be left intact by
announcing "duplicate" and allowing me to "ignore all duplicates"?

I'm running: Rails 2.3.5, Ruby 1.8.6, WinXP-Pro/SP3, Firefox 3.6.2,
Firebug 1.5.3,
MySQL 5.0.37-community-nt, Mongrel, Apache HTTP Server 2.2.15

Thanks in Advance,
Richard

RichardOnRails wrote:

Hi,

I've got an "expenses" table which I modified as follows:
added column "account_number"
renamed column "type" to "transaction_type"

Can I add CRUD for the columns with:
first: ruby script/generate model expense
then: ruby script/controller expense

Does this table not already have an associated Rails model?

Will all the existing CRUD for other columns be left intact by
announcing "duplicate" and allowing me to "ignore all duplicates"?

What do you mean?

I'm running: Rails 2.3.5, Ruby 1.8.6, WinXP-Pro/SP3, Firefox 3.6.2,
Firebug 1.5.3,
MySQL 5.0.37-community-nt, Mongrel, Apache HTTP Server 2.2.15

Nothing except versions of Rails and possibly Ruby is relevant here.

Thanks in Advance,
Richard

Best,

Thanks for your response.

Yes. The model consists only of the empty class definition.

But it's got views for show, new, etc. However, none of these views
are updated to reflect my new and renamed fields.

RichardOnRails wrote:
> Hi,

> I've got an "expenses" table which I modified as follows:
> added column "account_number"
> renamed column "type" to "transaction_type"

> Can I add CRUD for the columns with:
> first: ruby script/generate model expense
> then: ruby script/controller expense

Does this table not already have an associated Rails model?

Yes. The model consists only of the empty class definition.

But it's got views for show, new, etc. However, none of these views
are updated to reflect my new and renamed fields.

> Will all the existing CRUD for other columns be left intact by
> announcing "duplicate" and allowing me to "ignore all duplicates"?

What do you mean?

Will these new fields be appended to the controller and views without
negatively affecting the existing fields?

In short is there some way to achieve the same result as if I had
chosen the client's wishes initially, short of me manually adjusting
everything?

You must have a look at the code for the views, understand the code
(which is not a bad idea) and modify it to achieve what you want. But
first modify your tests, check they fail (as the new data is not yet
displayed) then modify the views and check the tests pass.

But even before that make sure that you have committed your code to
your version control system (git probably).

Colin

Hi Colin,

Thanks for joining the conversation. I appreciate it.

You must have a look at the code for the views ...

I have looked at the views in my app and understand them well. That
enabled by use existing and create new tools in Ruby that allow me to
make fine-combed searches in my app's code and make whole sale changes
semi-automatically.

So to make the changes I needed to the database, I used Rail's tool
for that purpose: migration.

As I just said, I used my tools to bring the app to compatibility with
the DB changes.

But the two new fields in the expenses table (added via migration) are
not reflected in the four app\views\expenses files. I can modify
these four files manually with ease. But some book I perused led me
to think that two tools would do that for me automatically:

first: ruby script/generate model expense
then: ruby script/controller expense

If they'd do the job (which was my original post) of adding CRUD
elements to my existing CRUD, then I'd like to employ them. And I
could just employ them and learn right away that they worked or not.
If not, I could easily recover my previous state.

But perhaps there's a smarter way to do this job, or a nuance I should
be learn about. Hence my post to guys like you and Marnen. The
question about whether I use git or my external hard drive are
tangential to the issue I'm dealing with. Likewise, whether I use
formal or ad hoc testing.

Does this long response make any sense to you guys? Should I just
forget my wish to Rails' tools and make my humble changes manually?

Again, thanks for taking the time to consider my questions,
Richard

RichardOnRails wrote:
[...]

But the two new fields in the expenses table (added via migration) are
not reflected in the four app\views\expenses files. I can modify
these four files manually with ease. But some book I perused led me
to think that two tools would do that for me automatically:

first: ruby script/generate model expense
then: ruby script/controller expense

If they'd do the job (which was my original post) of adding CRUD
elements to my existing CRUD, then I'd like to employ them. And I
could just employ them and learn right away that they worked or not.
If not, I could easily recover my previous state.

Not quite. You do not need to change your model at all -- it will
figure out that the extra DB fields are there.

script/generate model and controller will not help. script/generate
scaffold might, but you're better off modifying your views manually.

[...]

The
question about whether I use git or my external hard drive are
tangential to the issue I'm dealing with. Likewise, whether I use
formal or ad hoc testing

Not really. Smart version control and smart testing are essential to
smart development: they give you the freedom to make bold changes with
confidence, and to roll back changes that don't work. Without both in
place, you're just hacking.

Best,

Thanks for an additional response, Marnen.

Not quite. You do not need to change your model at all -- it will
figure out that the extra DB fields are there.

Interesting ... may I conclude that a Rails app, at start-up,
consults the database the app points to and determines the fields and
their types of every table?

script/generate model and controller will not help. script/generate
scaffold might, but you're better off modifying your views manually.

I anticipated this response and decided to forge ahead and make
changes manually. I ran into a problem after I added some erb
comments to four CRUD modules in app\views\expenses. I'm working on
that right now.

> The
> question about whether I use git or my external hard drive are
> tangential to the issue I'm dealing with. Likewise, whether I use
> formal or ad hoc testing

Not really. ...

I'm not disputing the value of Agile Programming. But clients
wouldn't tolerate me taking time to employ "best practices of to last
century" and my current "client", my son, doesn't want me to take
time for them now: he wants results, and I am responding to his
wishes.

You have my word that I'll get Agile-ized after we reach a working
version 1 (or 1.1 ...). I promise :slight_smile:

Thanks to you and Colin for spending time on a wretch like me :-),
Richard

Hi guys,

I started the manual process on four files in app\views\expenses. I
made some benign to them and crashed. I'd appreciate any observations
you might offer about that.

My first change was to reorder fields in each of them. That has gone
without a hitch, so far as I can tell.

My second change was to add comments as place-markers for the pair of
fields I have to add to each of them. That caused one of them to
fail: index.html.erb (and perhaps the others will when I invoke them.)

I posted the commented and un-commented versions at http://www.pastie.org/962089.

Thanks in Advance for any ideas you might offer,
Richard

RichardOnRails wrote:

Thanks for an additional response, Marnen.

Not quite. You do not need to change your model at all -- it will
figure out that the extra DB fields are there.

Interesting ... may I conclude that a Rails app, at start-up,
consults the database the app points to and determines the fields and
their types of every table?

You may indeed.

script/generate model and controller will not help. script/generate
scaffold might, but you're better off modifying your views manually.

I anticipated this response and decided to forge ahead and make
changes manually. I ran into a problem after I added some erb
comments to four CRUD modules in app\views\expenses. I'm working on
that right now.

"Module" has only one meaning in a Ruby context, and I doubt that that's
what you're referring to. What's the actual problem?

> The
> question about whether I use git or my external hard drive are
> tangential to the issue I'm dealing with. Likewise, whether I use
> formal or ad hoc testing

Not really. ...

I'm not disputing the value of Agile Programming. But clients
wouldn't tolerate me taking time to employ "best practices of to last
century"

It is not up to your clients. It is up to you, as a developer, to
employ the best practices you know how to use. If you can't sell that
to your clients, then do you really want to work for clients who don't
understand the importance of doing it right?

(Anyway, if you take the time to set up testing, you'll probably get the
project done sooner.)

and my current "client", my son, doesn't want me to take
time for them now: he wants results, and I am responding to his
wishes.

No, you're not. You're giving him hacked, brittle results. That's
worse than none at all.

I used to develop without tests too. Never again.

You have my word that I'll get Agile-ized after we reach a working
version 1 (or 1.1 ...). I promise :slight_smile:

That will be too late. But better late than never.

Thanks to you and Colin for spending time on a wretch like me :-),
Richard

The only thing wretched about you is your continual attempts to justify
bad practices. Just stop, reprioritize, and do it right.

Best,

I forgot to post the symptom. When I tried to recreate it, the
symptom. I have a better one, but I'll post it on a new thread. So,
forget the last post.

Thanks again,
Richard

Hey Marnen,

> Interesting ... may I conclude ...
You may indeed.

Cool!

added some erb

> added some erb comments to four CRUD modules
"Module" ... I doubt that that's what you're referring to.

Your doubts are well founded

What's the actual problem?

I'm going to post it on a separate thread.

do you really want to work for clients who don't
understand the importance of doing it right?

Absolutely! First of all they paid me well. And if you've got kids to
feed or a mortgagee to repay, that's important. Secondly, clients
asked me to produce or modify code quickly, and they have a right to
buy Volkswagen code rather than Cadillac code, as do buyers for
cars.

> I am responding to his wishes.
No, you're not.

You're assuming he's some Neanderthal. In fact, he spent almost ten
years as the Internet Architect for a national organization.

You're giving him hacked, brittle results. That's worse than none at all.

That's not the view of my well-informed client. We've talked about
it.

I used to develop without tests too. Never again.

I happy that you have that luxury. But I'm a version of the earlier
you. So, like you, I get to Agile-land. But, like St. Augustine,
I'll give up sin, but not right now :slight_smile:

Very best wishes, with appreciation of your insights,
Richard

I think Volkswagen is a poor analogy. They may be basic cars but have
a reputation for high reliability. I think Toyota may be an better
comparison.

Colin

RichardOnRails wrote:
[...]

do you really want to work for clients who don't
understand the importance of doing it right?

Absolutely! First of all they paid me well. And if you've got kids to
feed or a mortgagee to repay, that's important.

Of course, but...

Secondly, clients
asked me to produce or modify code quickly, and they have a right to
buy Volkswagen code rather than Cadillac code, as do buyers for
cars.

Like Colin, I think this is a poor analogy. What I'd say about my own
practise is this: I'll be happy to develop a VW or a Cadillac as the
project requires. What I will not do -- ever -- is skimp on the safety
features. Regardless of whether I sell my clients a VW or a Cadillac, I
have too much pride in my work to sell them a clunker that will be in
the shop all the time. I'm not willing to compromise on quality -- and
test-first development helps ensure that I can develop high-quality
software quickly.

If someone wants a car made with substandard materials, or with steering
that loses control, he will not find it on my lot. I can make that
guarantee because of my testing procedures.

> I am responding to his wishes.
No, you're not.

You're assuming he's some Neanderthal. In fact, he spent almost ten
years as the Internet Architect for a national organization.

That doesn't impress me without knowing more about the organization and
his role there. Too many big organizations don't understand the 'Net.

You're giving him hacked, brittle results. That's worse than none at all.

That's not the view of my well-informed client. We've talked about
it.

Waiiiiiiiit...so it's up to your client to tell you whether you're
hacking? WTF? How is he even in a position to know?

I used to develop without tests too. Never again.

I happy that you have that luxury.

It is not a luxury. It is a necessity. (Actually, I'd really like to
do proof-carrying code, but I'm not sure how feasible that actually is.)
It only seems like a luxury till you try it and watch it saving your
ass.

But I'm a version of the earlier
you. So, like you, I get to Agile-land. But, like St. Augustine,
I'll give up sin, but not right now :slight_smile:

Are you sure you want to model your behavior on a fairly hypocritical
line? :slight_smile:

Very best wishes, with appreciation of your insights,
Richard

Best,

Hi Colin,

I think Toyota may be an better comparison.

Good point.

BTW, I started to employ unit-tests. You and Marnen have beaten me
into submission :slight_smile:

Sincere best wishes,
Richard

Hi Marnen,

have too much pride in my work to sell them a clunker that will be in
the shop all the time. I'm not willing to compromise on quality -- and
test-first development helps ensure that I can develop high-quality

What you're claiming is that to not employ formal testing is
tantamount to shoddy work. But the proof is in the pudding. I never
would have survived as an independent computer consultant for decades
if potential clients suspected I did shoddy work. They always new
what my previous engagements had been and I'm sure checked to their
heart's content.

And I was always constrained to use the client's chosen programming
language though I'd often wished I could use something better.
Introducing foreign ideas like writing tests while no visible repairs
or new functionality emerged would not fly. Finally, the fact that I
didn't use formal testing regimes does not mean that I did no testing!

That doesn't impress me without knowing more about the organization and
his role there. Too many big organizations don't understand the 'Net.

So you think a guy with the title Internet Architect in a national
organization in constant computer communication with in multiple
cities in almost every state in the U.S. might just be boob when it
comes to the Internet? Do you think he might also be a jerk even if
he graduated college summa cum laude from an accredited university
might be unsophisticated. And that he's developing through me an
expense tracking system for two private schools he owns and operates
might not have a clue as to the impact of code I/m writing.

I work on this for two reasons. (1) To help my son reduce the burden
of managing a small enterprise.and (2) after toying with Ruby and
Rails for years in retirement, to finally dig in to these technologies
and hang out my shingle again offering web development services for
small business.

Waiiiiiiiit...so it's up to your client to tell you whether you're
hacking? WTF? How is he even in a position to know?

YES. And I hope you think I've answered the second question. He's
written a ton of Java and WSDL and Unix and Linux and Windows and
plenty of other stuff I know nothing about, like those packages for
administering large organizations.

> But I'm a version of the earlier
> you. So, like you, I get to Agile-land. But, like St. Augustine,
> I'll give up sin, but not right now :slight_smile:

Are you sure you want to model your behavior on a fairly hypocritical
line? :slight_smile:

Shucks, Marnen. I thought that last line was the best one in my
entire reply.

BTW, as I mentioned to Colin, I've been playing around with unit-
testing today. I feel like writing a generator to populate views when
columns are added/renamed/dropped from a DB table. It annoys my that
there's no tool to do that.

Best wishes as always,
Richard

RichardOnRails wrote:

Hi Colin,

I think Toyota may be an better comparison.

Good point.

BTW, I started to employ unit-tests. You and Marnen have beaten me
into submission :slight_smile:

Glad to hear it!

Sincere best wishes,
Richard

Best,

Hi Marnen,

Glad to hear it!

Yes, but I already have a problem (posted on a new thread) and an
observation: Ruby unit-test is an example of brittle software. The
first one I wrote had all sorts of problems I could resolve. I wound
up taking a working sample and step-by-step transforming into my
desired test. If I have too many disappointments, I'll try out BDD
to see if it's any better.

Best wishes,]
Richard

RichardOnRails wrote:

Hi Marnen,

have too much pride in my work to sell them a clunker that will be in
the shop all the time. I'm not willing to compromise on quality -- and
test-first development helps ensure that I can develop high-quality

What you're claiming is that to not employ formal testing is
tantamount to shoddy work.

No; my point is a bit subtler than that.

Let's go back to the car analogy. If you want to make sure that you're
not building your car with substandard materials, you have to have some
way of knowing that the materials you're using are within spec. How do
you do that? You establish guidelines for the materials you will use
(purity, breaking strength, whatever), and then you assay the materials
to make sure they meet these guidelines. The assay is crucial: without
it, you'd never be able to guarantee that the materials were within
spec. You might get lucky and have the purest, strongest material in
the world, but then again, you might have garbage -- and without the
assay, you wouldn't know till it broke at 60 mph.

And so it is with software. You might have the best code in the world,
but without tests, how can you be sure of that? More importantly,
without tests, how can you refactor reliably?

But the proof is in the pudding.

Actually, you mean "the proof of the pudding is in the eating". :slight_smile:

I never
would have survived as an independent computer consultant for decades
if potential clients suspected I did shoddy work.

Just because your clients don't suspect it doesn't mean it isn't
happening.

They always new
what my previous engagements had been and I'm sure checked to their
heart's content.

Which tells them very little. If they understood enough to check over
your previous projects really thoroughly, then they wouldn't need to be
hiring you in the first place, because they could do the job themselves!

And I was always constrained to use the client's chosen programming
language though I'd often wished I could use something better.
Introducing foreign ideas like writing tests while no visible repairs
or new functionality emerged would not fly.

I don't buy it. The client is hiring the developer to produce the best
possible software within the constraints. "No tests" is never a
reasonable constraint.

Finally, the fact that I
didn't use formal testing regimes does not mean that I did no testing!

Good.

That doesn't impress me without knowing more about the organization and
his role there. Too many big organizations don't understand the 'Net.

So you think a guy with the title Internet Architect in a national
organization in constant computer communication with in multiple
cities in almost every state in the U.S. might just be boob when it
comes to the Internet?

In a word, quite possibly. I mean no disrespect to your son by saying
this; it's simply a sad fact that title inflation is rampant in this
field.

Do you think he might also be a jerk even if
he graduated college summa cum laude from an accredited university
might be unsophisticated.

Yes. I've met people whom that would describe.

And that he's developing through me an
expense tracking system for two private schools he owns and operates
might not have a clue as to the impact of code I/m writing.

Yes. If he knew the impact of the code that intimately, he wouldn't
need you to write it, now would he?

Generally speaking, our field is one where formal credentials are too
easily obtained by the undeserving. I've seen post after post on forums
pointing out that the English major who fell into programming because he
loves it is often a better developer than the guy with the shiny CS
degree.

I work on this for two reasons. (1) To help my son reduce the burden
of managing a small enterprise.and (2) after toying with Ruby and
Rails for years in retirement, to finally dig in to these technologies
and hang out my shingle again offering web development services for
small business.

Those are both excellent goals, and I wish you best of luck in both of
them. That's in fact why I've been harping on the importance of doing
things right.

Waiiiiiiiit...so it's up to your client to tell you whether you're
hacking? WTF? How is he even in a position to know?

YES. And I hope you think I've answered the second question. He's
written a ton of Java and WSDL and Unix and Linux and Windows and
plenty of other stuff I know nothing about, like those packages for
administering large organizations.

But the development is your responsibility, not his. Unless something
got lost in the translation, it sounds like you're trying to foist off
onto your client concerns that are properly your responsibility.

> But I'm a version of the earlier
> you. So, like you, I get to Agile-land. But, like St. Augustine,
> I'll give up sin, but not right now :slight_smile:

Are you sure you want to model your behavior on a fairly hypocritical
line? :slight_smile:

Shucks, Marnen. I thought that last line was the best one in my
entire reply.

I agree. :slight_smile:

BTW, as I mentioned to Colin, I've been playing around with unit-
testing today.

Yes, I saw. Good luck!

I feel like writing a generator to populate views when
columns are added/renamed/dropped from a DB table. It annoys my that
there's no tool to do that.

You can use the scaffold generator, or (for a more sophisticated version
of the same thing) ActiveScaffold. But in most cases, this task is
beyond the scope of a generator: it needs actual human thought and is
not that susceptible to automation.

Best wishes as always,
Richard

Best,

RichardOnRails wrote:

Hi Marnen,

Glad to hear it!

Yes, but I already have a problem (posted on a new thread) and an
observation: Ruby unit-test is an example of brittle software. The
first one I wrote had all sorts of problems I could resolve. I wound
up taking a working sample and step-by-step transforming into my
desired test. If I have too many disappointments, I'll try out BDD
to see if it's any better.

RSpec is much nicer than Test::Unit. But Test::Unit isn't particularly
brittle, unless you're using it wrong. I'll look at your other thread.

Best wishes,]
Richard

Best,

What you keep talking about wanting to do is impractical for an
automatic procedure.
Consider your position:
You've run a generator that has created a bunch of boilerplate code
for you, which you've then fiddled with; edited to remove and
rearrange the fields - Rails doesn't know what you've done.
  Then you migrate to add a new column.

Where in the view would "Rails" put that if it were to update your
views for you? How will the generator look in your view for a
iteration through the records, or "know" what variable name you have
assigned to your object? (it would be pretentious, and dangerous, of
the framework to assume you've left it as the default)

Personally, I'd get grumpy if the framework started messing with my
views after they'd been created.

If you want the framework to do it for you; when you add your new
column, delete the existing view files and generate the scaffolding
again. That way the generator will know (because there's no existing
files) that it needs to create the boilerplate for you, and will have
all of the fields, including your new field, included.