Open jgm-ktg opened 4 years ago
What adapter do you use for pycasbin ?
Can you provide code example?
import casbin
import casbin_sqlalchemy_adapter
adapter = casbin_sqlalchemy_adapter.Adapter('postgresql+psycopg2:///casbin')
e = casbin.Enforcer('jgm_rbac_model.conf', adapter, True)
Core issue is that this expected casbin_rule to have an id column while cabin-dashboard did not create one.
type CasbinRule struct {
PType string `xorm:"varchar(100) index not null default ''"`
V0 string `xorm:"varchar(100) index not null default ''"`
V1 string `xorm:"varchar(100) index not null default ''"`
V2 string `xorm:"varchar(100) index not null default ''"`
V3 string `xorm:"varchar(100) index not null default ''"`
V4 string `xorm:"varchar(100) index not null default ''"`
V5 string `xorm:"varchar(100) index not null default ''"`
}
vs
class CasbinRule(Base):
__tablename__ = 'casbin_rule'
id = Column(Integer, primary_key=True)
ptype = Column(String(255))
v0 = Column(String(255))
v1 = Column(String(255))
v2 = Column(String(255))
v3 = Column(String(255))
v4 = Column(String(255))
v5 = Column(String(255))
Without a common database schema across the casbin family of tools, database support is crippled, right? There needs to be one project/version stream for database schema that is common to all adapters everywhere, or else chaos will result?
From the peewee docs:
In the above example, because none of the fields are initialized with primary_key=True, an auto-incrementing primary key will automatically be created and named “id”. Peewee uses AutoField to signify an auto-incrementing integer primary key, which implies primary_key=True.
Perhaps what happened is that peewee was making an id field so someone fudged the sqlalchemy one to be compatible with that?
Please let me know whether it is xorm-adapter (dashboard) or the python adapters that need to change. I need to fix this quickly to continue with my evaluation. I must get the dashboard, python and casbin-server working together off the same database in order to proceed with casbin.
casbin-server: For now, only Gorm Adapter is built-in
casbin-dashboard: Casbin-dashboard uses XORM to connect to DB
Even in the world of Go, projects are isolating themselves to different adapters? Does this make sense? How will compatibility be maintained between adapters that support the same database?
@hsluoyz do you have any comments about schema normalization and using the same database with different projects/adapters within the casbin ecosystem?
The following was created by casbin-dashboard in Postgres:
But when I go to pycasbin it seems to want an id column:
Are these projects compatible? Also hope to have casbin-server on the same database...