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.