Skip to content
This repository

Add support for CUBRID Database #317

Closed
kadishmal opened this Issue · 8 comments

3 participants

Esen Sagynov William Durand Cristiano Cinotti
Esen Sagynov

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?

William Durand
Owner

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

Cristiano Cinotti
Collaborator

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

Esen Sagynov

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.

Cristiano Cinotti
Collaborator

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

Esen Sagynov

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

Esen Sagynov

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.

Esen Sagynov

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?

William Durand willdurand closed this
William Durand
Owner

See #328

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.