Closed marcoarment closed 10 years ago
I agree that dropping support for custom table names would be the best solution. I only found the problem trying to use an existing database, and in this case changing the table name in SQLite is easier.
I also agree that walking through all classes with objc_getClassList
is not worth the effort. We also do not use custom table names.
Alright, let's just do it. We're not helping anyone by leaving in a feature that doesn't work.
Currently, subclasses may override this method to provide a custom table name instead of just using their class name:
I forgot that I even wrote that in, and I've always assumed in the rest of the code that the class name was always the table name. Humorously, custom table names don't actually work, and almost nobody noticed until now.
See #55.
Since FCModel scans the database schema after opening to get required property info, the only way to continue supporting custom table names is to use
objc_getClassList
to iterate through every class that exists to scan for FCModel subclasses at launch, which I think sucks.Since they don't work anyway and the only fix would suck, I propose removing custom table names.
I know that some people have maintained forks here with custom table names or prefixes. I've chosen not to integrate them into FCModel for simplicity, easy debugging, and reasons like this — to me, this is a clear win for convention over configuration. You have a model class named OCPost? It's in a table named OCPost.