Add Support for other ORMs about activeadmin HOT 235 CLOSED

Yes this is definitely something on our Roadmap. So we've got a few requests for Mongoid. Any other specific ORMs for "official" support?

from activeadmin.

First, thanks for the gem @gregbell!

+1 for Mongoid so I can use active_admin on my current project.

from activeadmin.

How about using something more abstract for db support?

from activeadmin.

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".

from activeadmin.

Maybe ianwhite/orm_adapter could help in this? I believe it's what devise
uses under the hood.

from activeadmin.

+1 for Mongoid. That'd be a big help for me.

from activeadmin.

@jc00ke Thanks for the suggestion. This seems like a great starting point.

from activeadmin.

Datamapper support would be awesome too.

from activeadmin.

Redis and Riak for me

Sent from my iPad

On 13 May 2011, at 22:38, [email protected] 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)

from activeadmin.

+1 for mongoid support

from activeadmin.

+1 for Mongoid support

from activeadmin.

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 ;)

from activeadmin.

+1 for mongoid!

from activeadmin.

Over in RailsAdmin land, they're considering using either OrmAdapter or Veneer in order to support a wider range of options.

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

Yes, this would be so awesome. +1

from activeadmin.

If you want a poll, then I'd definitely vote for mongoid :)

from activeadmin.

+1 for mongoid.

from activeadmin.

Second @drewda's OrmAdapter suggestion, especially since it's already a dependency of devise.

from activeadmin.

+1 for mongoid

from activeadmin.

+1 for mongoid

from activeadmin.

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

from activeadmin.

+1 mongoid!

from activeadmin.

+1 for DataMapper

from activeadmin.

+1 mongoid

from activeadmin.

+1 mongoid

from activeadmin.

Why not just do it via ActiveModel?

from activeadmin.

+1 ActiveModel

from activeadmin.

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

from activeadmin.

Hmm, I guess I'm just thinking about the presentation, rather than the other side of it too.

from activeadmin.

+1 for Mongoid, please =)

from activeadmin.

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.

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for mongoid

from activeadmin.

+1 Redis

from activeadmin.

What's the status? (+1 Mongoid)

from activeadmin.

+1 for Mongoid

from activeadmin.

+2 for Mongoid !

from activeadmin.

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.

from activeadmin.

@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.

from activeadmin.

@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)

from activeadmin.

+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?

from activeadmin.

@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

from activeadmin.

@gregbell

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 ;)

from activeadmin.

+1 for Mongoid.

from activeadmin.

@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.

from activeadmin.

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.

from activeadmin.

+1 for Mongoid support

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid (whats the status?)

from activeadmin.

@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

from activeadmin.

+1 for MongoId!!

from activeadmin.

using mongoid, watched Ryan Bates's newest video, tried the gem, didn't work, so a friendly vote for +1 Mongoid!

from activeadmin.

+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?

from activeadmin.

@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)

from activeadmin.

I would like to see Mongoid support

from activeadmin.

It will be great to have datamapper support!
Mongoid can be useful too =)

from activeadmin.

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

from activeadmin.

@ebeigarts - great stuff - this works. One needs to define all the fields manually but it's a bit step forward!

from activeadmin.

+1 for datamapper!! :)

from activeadmin.

+1 for mongoid ;)

great job folks!

[]'s

from activeadmin.

+1 for MongoID :)

from activeadmin.

Mongoid 👍

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid support

from activeadmin.

+1 for ActiveResource support

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for DataMapper

from activeadmin.

+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.

from activeadmin.

+1 for Mongoid

from activeadmin.

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!

from activeadmin.

I will give this a try soon. I saw your fork/branch yesterday but didn't think it was ready for testing yet.

from activeadmin.

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-users failed on assets

  cause is : comments require a database, which I have not

• disabling comments in config/initializers/active_admin.rb enables rails generate active_admin:assets

  config.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

from activeadmin.

@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.

from activeadmin.

@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.

from activeadmin.

sounds great!

from activeadmin.

@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:)

from activeadmin.

+1 on Redis. Would be awesome to able someow edit translations, stored with Redis, via ActiveAdmin.

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 MongoDB

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

Mongoid is quite popular for NoSQL in Rails.

So +1.

Does any official roadmap for Mongoid integration exist ?

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.

+1 for Mongoid

from activeadmin.