SPOD @:table("name") how to get the TABLE_NAME?

[theRemix]

How can i get the table name that is set by SPOD macro @:table("name") ?

do i have to set both macro and add a static var?

@:table("names")
class Name extends sys.db.Object{

  // THE OLD WAY
  public static var TABLE_NAME = "names";


} 

i tested accessing the class Metadata, and it broke.

Undefined property: _hx_class::$__meta__ (errno: 8) in /lib/haxe/rtti/Meta.class.php at line #6Undefined property: _hx_class::$__meta__

when i check the compiled class.php file, i see __meta__

static function __meta__() { $args = func_get_args(); return call_user_func_array(self::$__meta__, $args); } 
static $__meta__;

is there some magic field generated in macro that i couldn't find with Reflect/Type?

like Name._TABLE_NAME ?

[theRemix]

I found that this works:

MyTable.manager.dbInfos().name;

not as pretty as MyTable.TABLE_NAME though.

[Sam MacPherson]

@:NAME is for compiler meta data. You can't access this at runtime.

@NAME is for runtime meta data.

[theRemix]

oh yes, thanks for the reminder. i'm still getting used to these macros.

do you know of a better way to access the value of the compiler meta data then?

other than MyTable.manager.dbInfos().name;

[Hugh]

Hi,

Don't know too much about it, but you could maybe have a helper:

class TableObject extends sys.db.Object{

   public var tableName(get,null):String;

   function get_tableName() { return manager.dbInfos().name; }

}

class Name extends TableObject {....

Hugh

[Alexander Kuzmenko]

This approach fails as SPOD macros expects every class extending sys.db.Object to represent real table.

Does anyone know, how to tell SPOD this is just a helper class?

среда, 20 ноября 2013 г., 8:30:25 UTC+4 пользователь Hugh написал:

[David Elahee]

I remember you can do an @:skip or something like that... Good luck

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.

[Jason O'Neil]

@Alex: You can extend `sys.db.Object` and even though the build macros will run, they will do no harm. 

A few thoughts:

• You don't have to create a `static var manager:Manager<TableObject>` for your helper class.  Without it you don't have much to worry about, no SQL will be attempted etc.
• Haxe never automatically creates tables for your objects.  You can use `sys.db.TableCreate` for tables you do want to create, but just don't call it for your helper class.
  
• If you use NC's dbadmin library, that does automatically offer to create a table for any class that extends sys.db.Object, which might include your helper.  You can just choose not to create it, or what I did, is made a fork that looks for @noTable metadata and respects it.  You don't have to worry about this unless you use dbadmin though
• If you use @:skip on your helper as David suggested it should have no effect on the Table generation of sub-classes
  

[Alexander Kuzmenko]

Thanks for explanation.

@:skip is exactly what i need :)

среда, 20 ноября 2013 г., 12:36:00 UTC+4 пользователь Jason O'Neil написал:

[Juraj Kirchheim]

I don't really see the problem. If the whole issue here is that
`MyTable.TABLE_NAME` is shorter, then use something like this:

import sys.db.*;

class DbTools {
static public inline function getName<A:Object>(table:{ var
manager(default, null):Manager<A>; }):String
return table.manager.dbInfos().name;
}

using DbTools;

//Tadaaaaaaaaaa:
MyTable.getName();

Generally, sys.db.RecordInfos *is* the better way to "access the value
of the compiler meta data". All table information is in that object.
It's definitely a lot better than using reflection or runtime
metadata, which both are not even type safe to start with.

Regards,
Juraj