schematics

schematics copied to clipboard

Make an AbstractType which has no validation and allows any kind of data to be stored. This makes the choice to not use a specific type explicit and allows people to store freeform data.

If the data is freeform, I believe this type should allow the to_native and to_primitive functions to be defined at instance creation time. This means each instance of an AbstractType can be configured for different behavior.

+1 for creating a new issue for new features! Will work nicely w/ our changelog :)

Exactly!

On Thursday, September 26, 2013, Brad Dickason wrote:

+1 for creating a new issue for new features! Will work nicely w/ our changelog :)

— Reply to this email directly or view it on GitHubhttps://github.com/j2labs/schematics/issues/167#issuecomment-25214312 .

How did you envision the instance-creation-time configuration looking? I've got some ideas for some options, but they may not be flexible enough or the wrong kind of flexibility.

I believe you are asking for a hypothetical model, so here is what I have in mind. Rough sketch, for sure.

class Foo(Model):
    s = StringType()
    a = AbstractType()

and then perhaps code like this could be possible.

>>> f = Foo({'s': 'some string', 'a': 'another string'})
>>> f.validate()
>>> f.a = 5
>>> f.validate()
>>>

If that was true, you could use any type you want inside a dict and validation would pass.

You could, in theory, create a type that validates when it's value is a string or a number, but throws an exception if it's value is a list.

Thinking out loud, btw, so let me know if this feels weak to you for any reason.

No, I get that. I was looking for elaboration on this line: "I believe this type should allow the to_native and to_primitive functions to be defined at instance creation time." That wouldn't be directly supported by an abstract base with pass primitive/native/validate functions.

Ohhh, hmm... that's an interesting idea.

We should do that too, but only let the abstract type do it.

What a neat idea.

On Mon, Dec 2, 2013 at 10:05 AM, Steven Cummings [email protected]:

No, I get that. I was looking for elaboration on this line: "I believe this type should allow the to_native and to_primitive functions to be defined at instance creation time." That wouldn't be directly supported by an abstract base with pass primitive/native/validate functions.

— Reply to this email directly or view it on GitHubhttps://github.com/j2labs/schematics/issues/167#issuecomment-29624272 .

Wait, wasn't it your idea from the original issue? :)

HA. Yes. It's been a while, so I forgot. :)

On Mon, Dec 2, 2013 at 10:08 AM, Steven Cummings [email protected]:

Wait, wasn't it your idea from the original issue? :)

— Reply to this email directly or view it on GitHubhttps://github.com/j2labs/schematics/issues/167#issuecomment-29624640 .

Okay, so to land on the decision for now:

• We want abstract type to truly be pass for now (this means it will likely be little more than a subclass of BaseType with some docstring)
• Any constraining of types will have to be done in more concrete types. This means my example will likely because a AnyPrimitiveType that constrains types to those (and the other, AnySimplePrimitiveType).
• We may in the future lift up some generic type constraining logic to AbstractType if we see fit, or else provide some sort of type-choice concrete implementation of AbstractType.

Sound about right?

Okay, so to land on the decision for now:

• We want abstract type to truly be pass for now (this means it will likely be little more than a subclass of BaseType with some docstring)

I wonder if a better fix is to call the BaseType an AbstractType and then provide documentation supporting it's customizable options?

• Any constraining of types will have to be done in more concrete types. This means my example will likely because a BasePrimitiveType that constrains types to those.
• We may in the future lift up some generic type constraining logic to AbstractType if we see fit, or else provide some sort of type-choice concrete implementation of AbstractType.

Can you elaborate on what this means?

Sound about right?

— Reply to this email directly or view it on GitHubhttps://github.com/j2labs/schematics/issues/167#issuecomment-29633866 .

I wonder if a better fix is to call the BaseType an AbstractType and then provide documentation supporting it's customizable options?

It might be for the start. I wonder if my primitive/anytype stuff shouldn't even be the same pull. I can take a crack at this doc soon.

Can you elaborate on what this means?

This is entirely hypothetical, but I'm saying that at some point in the future we may find some of the stuff I've done for the any-primitive type to be more generally useful (e.g., for generally allowing a value to choose between 2+ types). My statement was that we'd watch out for this and let it emerge when it does, if it does.

Ah ok. That works for me.

On Mon, Dec 2, 2013 at 1:53 PM, Steven Cummings [email protected]:

I wonder if a better fix is to call the BaseType an AbstractType and then provide documentation supporting it's customizable options?

It might be for the start. I wonder if my primitive/anytype stuff shouldn't even be the same pull. I can take a crack at this doc soon.

Can you elaborate on what this means?

This is entirely hypothetical, but I'm saying that at some point in the future we may find some of the stuff I've done for the any-primitive type to be more generally useful (e.g., for generally allowing a value to choose between 2+ types). My statement was that we'd watch out for this and let it emerge when it does, if it does.

— Reply to this email directly or view it on GitHubhttps://github.com/j2labs/schematics/issues/167#issuecomment-29645919 .

Any suggestions for how to do this? I have a sqlalchemy.JSON field that is a nested dict with a somewhat complicated structure. I don't care about validating the data besides being sure its a valid dict. Is a custom type the right thing to do?

Same here. In OpenAPI I'm having an object field with additional properties defined in the next way:

data:
    type: object
    additionalProperties: true

So it matches agains any JSON object but I can't find a way to define this in schematics.

@Jbat1Jumper there is no strict JSON type, but you can do a field that accepts anything by using BaseType()

@WyseNynja If you want to make sure it is a dictionary, you can create a DictType(BaseType)

@Jbat1Jumper there is no strict JSON type, but you can do a field that accepts anything by using BaseType()

@WyseNynja If you want to make sure it is a dictionary, you can create a DictType(BaseType)

Is there a way to have a JSON with only 2-3 supported types? Currently DictType(BaseType) supports any type. I wanted to restrict this to lets say, NumberType and StringType. So basically I am looking at something like a Union of types as follows:

class MyModel(Model):
    field1 = DictType(UnionType(StringType, NumberType))

is this possible or is there a workaround?

EDIT:

There is a UnionType. (I couldn't find this one in the documentation but was able to find it in the source code) usage:

class MyModel(Model):
    field1 = DictType(UnionType((StringType, NumberType)))