search

ufront / ufront-orm

The Object Relational Mapper, allows easy, type-safe access to your database. Builds on Haxe's SPOD but adds macro powered relationships, validation and client side usage
MIT License
13 stars 4 forks source link

@:relation don't work #5

Closed sebpatu closed 10 years ago

sebpatu commented 10 years ago

Hi, its not possible to use regular @:relation with a ufront linked Spod. Because of a bug in Spod standard class!

ufront Objects have SUId type of id by defaut, and Spod standard has SId by defaut. But in RecordMacros.hx line 353 you'll see that standard Spod expects id in relations to be unsigned and create a field with signed type.

For example: create a ufront Spod object with a relation called uid that link to another ufront Spod object (for example DBUsers). and use ufadmin to create the table. you'll get sql error. If you explicitly declare the relation id like this: public var userid : SUInt; @:relation(userid,cascade) public var user : DBUsers; you'll get a compiler error! saying "Relation key should be SInt".

i don't know if you have a workaround in ufront until haxe standard is fixed. but until then it won't work.

Thanks Seb

sebpatu commented 10 years ago

i created a bug request in haxe github: https://github.com/HaxeFoundation/haxe/issues/2965

sebpatu commented 10 years ago

in fact i fixed it here: https://github.com/HaxeFoundation/haxe/pull/2967

jasononeil commented 10 years ago

Thanks @sebpatu

The fix looks good, once you re-submit it let me know. Once it gets accepted I can include the patched file in ufront-orm until the next Haxe release. I'll leave this issue open until the new Haxe release is out or I have included a patched file as a workaround.

jasononeil commented 10 years ago

I've changed the ID of ufront.db.Object to SId anyway as SUId doesn't work on SQLite. Anyone who has a database with 2billion+ rows and is worried by the choice can probably write their own class with their own ID I think :)