Add Support for other ORMs
fbjork opened this issue · comments
First of all great job on active_admin! Impressive and really easy to get up and running.
Any plans to support other ORMs like Mongoid?
Yes this is definitely something on our Roadmap. So we've got a few requests for Mongoid. Any other specific ORMs for "official" support?
First, thanks for the gem @gregbell!
+1 for Mongoid so I can use active_admin on my current project.
How about using something more abstract for db support?
Yes agreed. We'll have to abstract the concept of data stores and data access. I'm just trying to get a sense for which ORMs people are interested in "Out of the Box".
Maybe ianwhite/orm_adapter could help in this? I believe it's what devise
uses under the hood.
+1 for Mongoid. That'd be a big help for me.
Datamapper support would be awesome too.
Redis and Riak for me
Sent from my iPad
On 13 May 2011, at 22:38, gregbellreply@reply.github.com wrote:
Yes agreed. We'll have to abstract the concept of data stores and data access. I'm just trying to get a sense for which ORMs people are interested in "Out of the Box".
Reply to this email directly or view it on GitHub:
#26 (comment)
+1 for mongoid support
+1 for Mongoid support
I think (and I might be open to flame-bait here) that the most widely used NoSQL database for primary datastore for apps is mongodb. As for the ODM my impression is that Mongoid seems to be the more popular one. Therefore I would say that Mongoid would be head on the NoSQL list.
Maybe github needs polls ;)
+1 for mongoid!
Over in RailsAdmin land, they're considering using either OrmAdapter or Veneer in order to support a wider range of options.
+1 for Mongoid
+1 mongoid
+1 for Mongoid
Yes, this would be so awesome. +1
If you want a poll, then I'd definitely vote for mongoid :)
+1 for mongoid.
Second @drewda's OrmAdapter suggestion, especially since it's already a dependency of devise.
+1 for mongoid
+1 for mongoid
Also interested in this (for DataMapper).
From a quick look into taking a stab at it, ORM adapter probably needs to be extended to be aware of more data (types of columns, being able to enumerate assocations on a model). Also, InheritedResource is pretty coupled to ActiveRecord and its finders would probably need to be overridden (and/or ORM adapter also needs to abstract out the ability to query on collections).
Veneer is probably a better starting point, currently, since it has support for introspecting the associations on a model. https://github.com/kaapa/veneer/commits/properties
+1 mongoid!
+1 for DataMapper
+1 mongoid
+1 mongoid
Why not just do it via ActiveModel?
+1 ActiveModel
ActiveModel doesn't support querying & introspection (of a table/collection); it's just a consistent representation of the individual resources - and gives you all those nice helpers, like validation
Hmm, I guess I'm just thinking about the presentation, rather than the other side of it too.
+1 for Mongoid, please =)
I'm interested in picking this up for DataMapper. To follow on from @nevir's comment, it looks like one way to get started would be to build support for DM/other ORMs low-down into inherited_resource/ has_scope, given that ActiveAdmin is built on, and strongly coupled to these gems.
+1 for Mongoid
+1 for Mongoid
+1 for Mongoid
+1 for Mongoid
+1 for mongoid
+1 Redis
What's the status? (+1 Mongoid)
+1 for Mongoid
+2 for Mongoid !
This is open-source. I don't think asking "what's the status" is particularly helpful. The fork button exists for a reason!
AA is strongly coupled to has_scope / inherited_resources. Decoupling here would be a start.
@myabc Thanks, I know how/when to use the fork button. As a matter of fact, I've even indirectly contributed to AA via that same fork button on Kaminari.
I think that asking what the status is is entirely fair considering the following comment from @gregbell himself:
"Yes this is definitely something on our Roadmap." (Dated ~2 months ago)
I'd love to contribute directly to AA but I simply don't have the time to commit right now.
@tmileski That wasn't meant to be directed at anyone in particular. I am receiving a number of +1s in my Inbox, and thought it would be better to try to direct the conversation into a more constructive discussion of what needs to be addressed to get multi-ORM support working.
But I go get what you say about the roadmap!
On Jul 12, 2011, at 4:00 PM, tmilewski wrote:
@myabc Thanks, I know how/when to use the fork button. As a matter of fact, I've even indirectly contributed to AA via that same fork button on Kaminari.
I think that asking what the status is is entirely fair considering the following comment from @gregbell himself:
"Yes this is definitely something on our Roadmap."
I'd love to contribute directly to AA but I simply don't have the time to commit right now.
Reply to this email directly or view it on GitHub:
#26 (comment)
+1 for Datamapper / Generic ORM-Support
And I would like to get my hands dirty in participating in a generic orm-adapter solution. My toughts about it:
- Do not start with a single plain datamapper fork, it will not be merged back.
- Instead decide about an orm adapter, (ORM-Adapter or veneer?)
- Start to port the current active record backed system to the choosen orm adapter
- Get this merged into master
- Start building DataMapper/Mongoid etc support with the new features by orm-adapter
Are there better ideas around?
@mbj That seems like a great plan for getting started.
The first thing we should do is a brief audit of the existing Active Admin code base to document all the features the data store will have to support. I would like to see Active Admin define the public API required for adapters to implement the existing features. Then we can make a decision on which generic ORM to use.
From my perspective, the biggest hurdle will be the filtering, scoping and "belongs_to" behavior on the index screens. We will need to write adapters for any support data store, but it needs to start with documenting the API.
I'm really tight for time, so if anyone has a chance, maybe we could start a wiki page that starts to document a plan
Sorry for reacting not that fast.
I'll first start to read the source "in depth" and make sure I understand the hurdles you mentioned. After that I'll try to start an adapter API description. Gist based. After that we can decide to use the ORM-Adapter with the biggest "already works" part. Im sure we have to extend one of the already existing ORM-Adapters. We should start to talk to the ORM authors to make sure our requirements get their support.
As I'm really tight for time too, do not expect results this week ;)
+1 for Mongoid.
@mbj, my suggestion would be to consider the orm_adapter gem you mentioned earlier, it's already being used by Devise, which gives it an slight advantage over veneer. As for the supported ORMs, it supports both ActiveRecord, DataMapper and Mongoid rather than the (according to Ruby-Toolbox and the spam in this topic) less used MongoMapper.
As far as I can tell from my brief looks through the code of active_admin and Veneer/OrmAdapter's api's, the major issue would indeed be the lack of scopes, which are used rather extensively throughout the code. Including support for the belongs_to-behavior should be rather easy to solve in comparison I think, requiring a small extension (contribution?) to the adapter's classes.
Can't wait for this to support Mongoid, congratulations on an amazing project however. I'm tempted to switch back to SQL just to play with it on my latest project.
+1 for Mongoid support
+1 for Mongoid
+1 for Mongoid
+1 for Mongoid
+1 for Mongoid (whats the status?)
@nextpulse The problem with orm_adapter is that it's focused on abstracting the query interfaces - but not introspection. To make it useful for active admin, we'd need to build in support for that.
@kaapa's properties branch of veneer is probably the best starting point: https://github.com/kaapa/veneer/tree/properties
+1 for MongoId!!
using mongoid, watched Ryan Bates's newest video, tried the gem, didn't work, so a friendly vote for +1 Mongoid!
+1 Mongoid. Also just watched the Ryan Bates screencast - would LOVE to use this for a couple companies I work for but they're all using mongoid.
I see back in June support for other ORMs was on the roadmap. Any updates as to where on the roadmap?
@gregbell Sorry for not reacting that fast. Daily business is hard ;) I'm currently purging rails from my default development stack moving on to other targets. So I cannot invest time in active_admin to build support for datamapper (my favorite orm). I canceled my plans to port active_admin to orm adapter. Sorry.
(Edit: Spelling)
I would like to see Mongoid support
It will be great to have datamapper support!
Mongoid can be useful too =)
It would be very hard to get the filters working, because meta_search supports only ActiveRecord.
Maybe we could start by adding support without the filters and comments. Working example with Mongoid - https://github.com/ebeigarts/mongoid_active_admin_app
@ebeigarts - great stuff - this works. One needs to define all the fields manually but it's a bit step forward!
+1 for datamapper!! :)
+1 for mongoid ;)
great job folks!
[]'s
+1 for MongoID :)
Mongoid 👍
+1 for Mongoid
+1 for Mongoid support
+1 for ActiveResource support
+1 for Mongoid
+1 for DataMapper
+1 for Mongoid
@yuki24 has said on Twitter that he has got it to work and will be adding a pull request to the main repo soon.
Fingers crossed it will be soonish.
+1 for Mongoid
Hey there! as I tweeted a few days ago, I did make adtiveadmin work with mongoid but what I did was just modifying some lines.
so right now I'm rewriting it with Rspec/Cucumber test and preparing for a pull request.
You can see the current change here: https://github.com/yuki24/active_admin/compare/master...enable_mongoid
index_as_table and show already work and tested with RSpec and Cucumber. Deletion works but has not been tested yet.
also I'm working on adding orm_adapter to make it easier to support other mappers as discussed above.
try the branch if you have time and give me your feedback. Thanks!
I will give this a try soon. I saw your fork/branch yesterday but didn't think it was ready for testing yet.
Hello @yuki24
My app is mongoid only and does not require active_record (that is no sql database, only a mongo one)
I made local edits from your code (I dropped a comment on #96bf39) to have app go further
-
rails g active_admin:install --skip-usersfailed on assetscause is : comments require a database, which I have not
-
disabling comments in
config/initializers/active_admin.rbenablesrails generate active_admin:assetsconfig.allow_comments_in = []
Generating assets should not require a database ... (looking like a famous issue on heroku cedar with rake assets:precompile :)
I had to do some more edits in initializer to fit into its authentication path, and I'm glad I found them easily
Then, admin interface shows up
This is great
Here are the gotchas I faced :
- index
sort cause an error in app - new | edit
empty form
I forked your fork, and will see how I can help
@yuki24 @thierryhenrio You guys have seen @ebeigarts fork right? It code for a working mongoid active admin (except without comments and filtering). I've gotten create, update, destroy, sort working based off of that fork with mongoid. All that he did was add an initializer (active_admin_mongoid_patchets.rb) to disable commenting and filtering and update sorting.
https://github.com/ebeigarts/mongoid_active_admin_app
What is difficult are the filters because they're reliant on meta_search which is active record only right now. I also think decent support for embedded documents needs to be added in before it's really useful.
@thierryhenrio thank you for the feedback! I'll try fixing rails generate active_admin:assets. also AcitveAdmin with only Mongoid is interesting so I will also try implementing it.
@marbemac yes, I've seen that fork from @ebeigarts. he posted some comments on my codelines as well and I totally agree with what he said. also I know that many things depend on active_record but that is what I am trying to solve. support for embedded documents sounds really nice.
sounds great!
@yuki24, I finally made a fresh fork...https://github.com/thierryhenrio/active_admin/tree/mongoid
(spec were red, and begin from green was easier for me)
there are 3 commits
- 7e5ad21 enabling faster red/green feedback for rspec stack, can be cherry picked
- 827684d can generate an active_admin:install for mongoid (--no-comments is required), can be cherry picked
- d5c14ba wip implementation
implementation is heavily inspired by your code and @ebeigarts insights
I picked orm_adapter, and it might not be that a good fit to active_admin context ...
I went from a fresh mongoid app, and add step beginning from cli, with rspec+cucumber being green
next goal : have fields showed in a default mongoid form (if can be:)
+1 on Redis. Would be awesome to able someow edit translations, stored with Redis, via ActiveAdmin.
+1 for Mongoid
+1 MongoDB
+1 for Mongoid
+1 for Mongoid
Mongoid is quite popular for NoSQL in Rails.
So +1.
Does any official roadmap for Mongoid integration exist ?
+1 for Mongoid
+1 for Mongoid
+1 for Mongoid
+1 for Mongoid
+1 for Mongoid
+1 for Mongoid
+1 for Mongoid
+1 for Mongoid
+1 for Mongoid
+1 for Mongoid