Namespace Tables

[Neves]

I want to create an app that enable each user to create they own
tables.
But I need a way that if user A create a table called product, and
user B create a table with same name, that each one be separated from
each other.

One solution would be create a owner field on the table, and filter
every query from user A, with owner=A and the same for user B. But
user A would have distinct fields from user B. But that would not be a
problem, since db.Expando enable that.

Other approach would be create the entity using a namespace, like
A_Product and B_Product, letting each user with they own tables.

One last option would have only one model called table, and have on it
a field called owner and tableName plus all the fields from all
tables. So the system would store all tables on one big table.

What would be the best way to go?
And how can I create a dynamic class in python. Example, a post to /A/
Product, I would have to create a model called A_Product, assign all
form fields sent, and save it. How can I create A_Product
dynamically?

[Calvin Spealman]

just a reminder: Kinds are not Tables. That being said, moving along...

you can build classes dynamically, so thats no trouble. you could
prepend the classname with some unique key, also.

or, you can just store with Expandos and add extra rules governed by a
set of UserDefinedProperty entities, making a Model class,
UserDefinedProperty that defines one property for some named used
defined kind.

--
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/

[Neves]

So, your suggestion is for the third option? The UserDefinedProperty
would be model first order properties, or would be defined on a single
one. Exemplo:

For the Product kind, the user A defined the follow properties:
name: StringProperty
published: BooleanProperty
price: FloatProperty

How My Table model would be?

First option:

TableModel:
owner: UserProperty
tableName: StringProperty
userDefined: UserDefinedProperty
name: StringProperty
published: BooleanProperty
price: FloatProperty

Second option:

TableModel:
owner: UserProperty
tableName: StringProperty
#dynamic ones:
name: StringProperty
published: BooleanProperty
price: FloatProperty

On the first option, how can I create UserDefinedProperty? It would be
a simple dictionary?

[Calvin Spealman]

What i am saying you would have a Model subclass named something like
UserKind, detailing what user owns it, the name, and any other
relevant information. You would then have UserKindProperty model class
who's parent is the UserKind, and which stores the name and type (as
some enumeration of typecodes mapping to the allowed property types)
of the property. Third, the actual data is stored in something like a
UserKindEntity model class, which references the UserKind is conforms
to and is a subclass of Expando. You can either use descriptors or
custom __setattr__ methods to test that any property set on the object
is the right type and matches the name of a defined property,
according to the UserKind's UserKindProperty objects.

Does that make sense?

Basically, you store all the data in Expandos, but you have some other
objects that define the rules the users define for their types.

[Neves]

I´ll try to express with code, to see if I understand.

class UserKindEntity(db.Expando):
owner = db.ReferenceProperty(UserKind)

class UserKind(db.Model):
owner = db.UserProperty()
name = db.StringProperty()

I can´t realize where UserKindProperty fits.

And now I see that I´ll need a place to store Properties Metadata.
For example, the user can create a field called born_date, and tell
the minimum and maximum value allowed.
Or create a field named code, and assign a inputMask to the metadata.

Should I extend the Property class? or should I store those Metadata
as Kinds?

Please, I need help to learn think on a non relational way.

[Calvin Spealman]

That property meta data is what the UserKindProperty entities would be
for. Each would describe one type of property on some user-defined
type.

Also, you are missing any way to reference what UserKind a UserKindEntity is.