Looking for maintainer[s]

[AlexDenisov]

As I mentioned in README the project is discontinued, because I don't have enough time to maintain and develop new versions.

If I continue, then I'd better start the project from scratch or change it radically, e.g.: protocols instead of inheritance; explicit conventions (names or special classes for relationships between entities) over preprocessor definitions; more abstract 'engine' implementation, with possibility to easily switch between sqlite versions (3,4) or even different DB engines. And of corse much more tests!

These tasks need a lot of time, which I don't have.

But still I see some activity around the project (does somebody really use it?):

• @tslater asked why project is dead
• people still open issues/send PRs
• @valerius continues implementation in his own fork: https://github.com/valerius/VinylRecord
• a few people sent me personal emails with some questions/suggestions/etc.

I'd like to ask community for a favor:

Please, let me know if you're interested in maintaining and developing of this project!

[neilabdev]

Hey Alex!

As before, hopefully I can assist wherever I can! As you’ve mentioned, my fork VinylRecord now exists which is is %99.9999 percent compatible with yours, minus one macro which automatically generates a foreign key which previously had to be done manually ( a minor change which I did a great reservation for compatibilities sake). Other than that, despite the documentations use of VinlyRecord, its a dummy subclass of ActiveRecord so you don’t loose any functionality by inheriting directly from your base case, and thus should remedy any likely pull request you may have with the discontinued project, etc, in addition to some new features, etc.

Regarding your proposed new implementation, I definitely like the protocol idea, even more getting rid of the preprocessor definitions AND/OR complimenting them with a means to map without preprocessor definitions, as swift doesn’t support preprocessor macros, thus limiting relationship declaration to subclasses of objective-c. Was thinking to add a new syntax which worked in addition to your macros which would allow mapping via static vars, similar to what you see in rails / grails, though perhaps you envision addressing this using the naming convention you spoke of. Either case, I think ease of use in swift will help even more rapid adoption do to its script like syntax, etc. Here was one example:

class Dog : ActiveRecord {
    static let mapping = [
        "breed":["column":"breed"],
        "owners":["has_may":Owner]
    ]
    static let constraints = [
            "breed": ["unique":true]
    ] 
    //@NSManaged var breed:NSString?  //@NSManaged IS @dyanmic in swift, which sucks :(
    var breed:NSString?
    var owners:[Owner]
}

Regarding the database selection, I think this is good, as long as a database implementation doesn't effect application code. E.g. allowing a developer to use special features that wouldn't work when using a different database implementation, such as using JSON storage in postgres but when you use mysql, application code would break. The reason this is not good is primarily from CocoaPods standpoint, if you use a Pod that expects a feature the Application doesn't provide, etc. I suppose this could be addressed by implementing table/database name-spacing which I thought to implement, but decided against it because the class models which ultimately become tables in the database have to be unique anyway. Though, allowing different storage engines makes the requirement more alluring again, but does bring additional questions... just a thought.

Anyways, your current implementation I think is pretty good. If it weren't for swift (which is still evolving), I would not have considered a new implementation but perhaps thats the best direction going forward. Regardless, its good to at least get a discussion going :)

Thanks for all the great work!

[paulocoutinhox]

I can maintain too. I made some PR for it.

[alexlee002]

Hi, I'm not sure if is appropriate to introduces my repo here.

I'm also developing my Active-record-like implementation, and I hope there are some people to make it better with me.
My repo is here:
https://github.com/alexlee002/patchwork