Re: [indyrb] Ruby Design Dicussion

From: Greg B.
Sent on: Monday, December 19, 2011 3:04 PM
UNION is slow because it does a distinct on all results. If you don't need it to be that way, do a UNION ALL. 

Greg Benedict
TGFI, Inc.
212 W. 10th Street, Studio C460
Indianapolis, IN 46202
Office [masked] x202 | Fax [masked]
Email [address removed] | Web 
www.tgfi.net

On Dec 19, 2011, at 2:55 PM, Neil Hastings wrote:

That's very good information.  How would I go about creating a list of all products?  Aren't Union queries really slow?  It's very interesting hearing that STI causing so many issues.  It will makes  not want to use it.

Thanks again Dave for the help!
Neil


On Dec 19, 2011, at 2:30 PM, Dave Christiansen wrote:

You could do it either way. I'm no fan of STI - it's a last-resort approach for me. I wish I could be more concrete about why that is, but all I can say is I've spent a lot of time ripping STI out of apps.

My preference is to create different models for each different thing, then use the plugin to give them shared stuff. 

David Christiansen
TechDarkSide.com
[masked] (mobile)



On Mon, Dec 19, 2011 at 7:46 AM, Neil Hastings <[address removed]> wrote:
Thanks Dave.  I haven't looked into plugins.  I read though the rails guides and I see lots of potential for them.  I'm not sure they will work in this case.

Would this require each model to have it's own table?  Or are you saying still use STI/SMI put use plugins for the shared functionality?  

Thanks,
Neil

On Dec 18, 2011, at 9:59 PM, Dave Christiansen wrote:

Have you considered creating an acts_as_product type plugin for it? The plugin could hold the generic product functionality and migration for the shared fields, but all the other stuff would be on your different product models. The rails guide for plugins are pretty good for showing you how to do this.

David Christiansen


On Sun, Dec 18, 2011 at 7:54 PM, Neil Hastings <[address removed]> wrote:
I'm having a design issue on an app I'm working on.  The app is basically a warranty/maintenance tracking system for products.  It's a Rails 3.1 app.  Since it's still in development (early) I'm keeping up with the latest and greatest.

The main piece of content for the app is a product.  There are different product types.  Each product type has several features:
  • Shared Fields/Validations/Rules
  • Individual Fields/Forms
  • Individual Validation

I've gone through a few different scenarios and here is what I have so far.  Thanks for any help, suggestions you might have.

STI - Single Table Inheritance.

It appears as if this method uses the most Rails out of the box.  The base Product Model has the main validation while the child models can have their own validations.  I'm using a single controller, I fell that the controller shouldn't really care what type of product it is working with.  All logic is either in the Model, Observer or something else yet to be seen.  The controller is in charge of finding the correct Model.  Currently I'm doing this based upon a parameter with this helper method.

  def product_model(product_type)
    klass = "#{product_type}Model".constantize
    klass.new
  end

The class just call product_model param[:type] and it has the object.  In early testing this works well.  I'm able to use presenters based upon the model name.  I'm using the methodology form Ryan Bates http://railscasts.com/episodes/287-presenters-from-scratch.

Basically, I pass the model object to the base presenter and it loads up the correct presenter.  I create haml files for the different product types and it loads up those forms.

From a database perspective, I can use Mongo or Mysql/Postgress.   I'm hoping to stick with Active Record just to due to my experience.  I've used Mongoid for an app before so if using a document store is a better idea, I'd be ok using it.

The rest of the app is focused around the product.  Including maintenance schedules, warranties, reminders, etc.  I do have plans of integrating with other systems from manufactures to get recommended maintenance schedules and warranties.  I was looking at the product types to be the focal points of the integrations.  Though that is yet to be seen, most likely most of these integrations will be pretty custom.

Custom/Domain

This option is a more custom approach.  It uses much less Rails out of the box.  In fact, it probably doesn't even have to be Rails.  I was thinking of a domain approach.  Where each product type can be defined in a class, then include a product module for shared functionality.  This would be a single Model with the types based upon the type field.  The product type domain class would be called form the controller,views rather then the model.  The Product Type Domain class would still include the Product for direct table access.  I would still use presenters for the view level.

Since the table structure is in defined in the product type, a schema less db makes the most sense here.

If this is a little to complicated for email, then I'd be happy to meet up somewhere to discuss.  Currently I'm leaning toward STI, but I do really like making something from scratch (it satisfies my control issues).

Cheers,
Neil Hastings




 




--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Neil Hastings ([address removed]) from indy.rb - The Indianapolis Ruby Brigade.
To learn more about Neil Hastings, visit his/her member profile
To unsubscribe or to update your mailing list settings, click here

Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Dave Christiansen ([address removed]) from indy.rb - The Indianapolis Ruby Brigade.
To learn more about Dave Christiansen, visit his/her member profile
To unsubscribe or to update your mailing list settings, click here

Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Neil Hastings ([address removed]) from indy.rb - The Indianapolis Ruby Brigade.
To learn more about Neil Hastings, visit his/her member profile
To unsubscribe or to update your mailing list settings, click here

Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Dave Christiansen ([address removed]) from indy.rb - The Indianapolis Ruby Brigade.
To learn more about Dave Christiansen, visit his/her member profile
To unsubscribe or to update your mailing list settings, click here

Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Neil Hastings ([address removed]) from indy.rb - The Indianapolis Ruby Brigade.
To learn more about Neil Hastings, visit his/her member profile
To unsubscribe or to update your mailing list settings, click here

Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy