Datamapper DataMapper → 1.0.0

Comments and changes to this ticket

• You flagged this item as spam.
  

  Deleted User February 16th, 2009 @ 10:30 AM

  Just to confirm that I've just hit the same issue so can verify that this ticket is valid.

  Also the workaround works (thanks Greg)

• You flagged this item as spam.
  

  Deleted User February 17th, 2009 @ 10:29 AM

  Having got a bit further with my app, I've now realized that I actually need some of my STI inherited models to have a different state_machine setup than the parent.

  I guess so that use cases such as this are not excluded ideally any patch should allow subclasses to define their own setup without stomping all over that of the parent model. Perhaps the tidiest solution would be where if a subclass defines it's own 'is :state_machine' block it will be used for that class and if it doesn't then the parent behavior would be inherited.

• 

  Martin Gamsjaeger (snusnu) July 12th, 2009 @ 01:24 PM

  • Assigned user changed from “Michael Klishin (antares)” to “Martin Gamsjaeger (snusnu)”
  • State changed from “unconfirmed” to “accepted”
  • Milestone set to “0.10.0”

  I can confirm this is still an issue with latest next branch. However, I'm not sure what would be the right way to tackle that, since I heard Dan mention that it's probably a good idea to use the state_machine plugin at

  http://github.com/pluginaweek/state_machine/tree/master

  under the hood since it seems to be a widely used and mature library that officially supports DM. I can only say that I'm all for that, because there's really no point in duplicating the effort of writing such a feature rich statemachine again.

  Additionally, I also heard Dan say that he actually wants to strip down dm-more in the future (I guess not for 0.10 though) to only contain the list of dm-more plugins that can be found in the release notes for 0.10.0RC1. This would mean that dm-is-state_machine wouldn't be part of dm-more anyway. If that will be the case, then I also see no real benefit in wrapping the state_machine plugin with dm-is-state_machine. state_machine alone will do the job (probably a lot better anyway).

  http://groups.google.com/group/datamapper/browse_thread/thread/eecd...

  In the meantime it's probably reasonable to provide a patch for the original issue this ticket deals with? @roovo, I'm not sure wether handling your extended scenario would make much sense in the light of my above comments?

  What do you guys think?

• You flagged this item as spam.
  

  Deleted User July 13th, 2009 @ 07:33 AM

  Thanks Martin - sounds like a sensible way forward to me. I can always add a new ticket in the future once what's included in dm-more is finalized if I feel there's a need for the extended scenario.

• 

  Dan Kubb (dkubb) October 4th, 2009 @ 09:33 PM

  • Milestone changed from “0.10.0” to “0.10.2”

  [project:id#20609 not-tagged:"0.10.0" milestone:id#51895 bulk edit command]

• 

  Dan Kubb (dkubb) February 1st, 2010 @ 04:33 PM

  • Milestone changed from “0.10.2” to “1.0.0”

  [bulk edit]

• 

  Dan Kubb (dkubb) March 30th, 2010 @ 07:57 PM

  • State changed from “accepted” to “resolved”

  (from [2b0548fac53c3417d9b04d838fea0e1f776951db]) [dm-is-state_machine] Fix certain STI scenarios

  This is probably not the cleanest way to solve the
  particular problem, but it works, and imho this
  gem is bound to be discontinued in favor of the
  state_machine gem maybe.

  [#799 state:resolved] http://github.com/datamapper/dm-more/commit/2b0548fac53c3417d9b04d8...