Add support for CUBRID Database #317

Closed
kadishmal opened this Issue Nov 22, 2012 · 8 comments

Comments

Projects
None yet
3 participants
Contributor

kadishmal commented Nov 22, 2012

There was a discussion on Appflower.com forum to add CUBRID support to Propel ORM.

I want to look into this issue and add CUBRID support to Propel, but wanted first to confirm if the core team accepts my contribution.

What would you respond on this?

Owner

willdurand commented Nov 22, 2012

It's ok to me. I've been contacted by CUBRID guys already, just no time to work on that.
If you want to work on adding CUBRID to Propel, no problem. Do it and don't forget unit tests ;)

Member

cristianoc72 commented Nov 22, 2012

+1 for me. Let me know how I can help.

Contributor

kadishmal commented Nov 23, 2012

All right, I will first fork, see what files require changes, then will comment here. @cristianoc72, yes I would be glad for your help! I will let you know.

Member

cristianoc72 commented Nov 23, 2012

@kadishmal I got a look to Cubrid documentation (it's really awesome!!) and I think your work'll be easier, if you use PDO driver.
Anyway, you could follow these steps:
1. write your own Propel\Generator\Platform\CubridPlatform class, which extends Propel\Generator\Platform\DefaultPlatform implementing Propel\Generator\Platform\PlatformInterface
2. write your own Propel\Generator\Reverse\CubridSchemaParser class, extending AbstractSchemaPareser, implementig SchemaParserInterface
3. write relative tests
Propel\Tests\Generator\Platform\CubridPlatformTest
Propel\Tests\Generator\Platform\CubridPlatformMigrationTest
4. write your own runtime adapter Propel\Runtime\Adapter\Pdo\CubridAdapter
5. run test suite and have fun!

Contributor

kadishmal commented Nov 23, 2012

@cristianoc72, that's a very helpful tip! I have already forked the repo and will work on it next week and will send the PR.

Contributor

kadishmal commented Nov 30, 2012

Hi, I've created all the necessary CUBRID files and started testing, but have encountered some hard-coded configurations for testing which I don't understand. I would be glad if someone could clarify them for me.

  1. tests/Fixture/bookstore/build.properties.dist this is that template file which gets populated with vendor specific information such as dsn, db login info, etc. However, there is this property disableIdentifierQuoting=true. Why is it true? Why on earth would anyone want to disable automatic vendor specific identifier quoting? There are many reserved words specific for each DB vendor. For CUBRID case, position is a reserved keyword that is used in bookstore schema, which is not quoted because disableIdentifierQuoting is true. I don't know how should I behave in this situation. If there is no specific reason for this to be true, I will change it to false and commit it along with CUBRID changes.
  2. What I don't understand as well is why would anyone want to force to disable foreign key checks, then create tables without required order like child tables coming before parent referenced tables, then enabling the foreign checks at the end? Is this hacking highly preferred in Propel community or what? The proper way is to create tables in right order and remove these hackish foreign key check disabling stuff. The thing is only MySQL allows to disable foreign key checks, meaning everything else will fail tests.

These are the files with wrong CREATE TABLE orders:

  • tests/Fixture/bookstore/behavior-concrete-inheritance-schema.xml: concrete_author should come before concrete_article.
  • tests/Fixture/bookstore/behavior-validate-schema.xml: validate_author - before validate_book.
  • tests/Fixture/bookstore/schema.xml: publisher - before book.
  • tests/Fixture/namespaced/schema.xml: publisher - before book.

For now, I updated these files placing parent referenced table definition before child referencing tables. Please comment on these suggestions.

Contributor

kadishmal commented Dec 3, 2012

I've got a problem and would appreciate if someone from Propel core team would help me. CUBRID database sets a 17 character limitation to a database name. However, Propel2 has several tests which use long database names (eg. bookstore-behavior 18 chars). Looking at Propel2's source code, it seems that these database names are hard-coded all around the source code, so it's not something I can change in one place in the configuration file.

What are other options I can refer to in order to run Propel2 tests?

Specifying a particular database name in DSN does sole this problem, but it creates another set of problem which block tests. Since CUBRID does not provide a hack to disable foreign key checks like MySQL does, I can't use the same database for different behavior-*-schemas.

So what are other options?

Owner

willdurand commented Sep 30, 2013

See #328

@willdurand willdurand closed this Sep 30, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment