Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need a "clean" way to add field types. #49

Closed
ghost opened this issue Jun 7, 2014 · 2 comments
Closed

Need a "clean" way to add field types. #49

ghost opened this issue Jun 7, 2014 · 2 comments

Comments

@ghost
Copy link

ghost commented Jun 7, 2014

Hi there,

I'm using django-netfields in my app and I while trying to display a table with netfields elements I ran into this:

ValueError: Unhandled field type for address (<class 'netfields.fields.InetAddressField'>) in search.

So, I looked in the code and so far, the only way I found was to override the "quite big" apply_queryset_options in the DatatableMixin class.

Could it be possible to have a more user friendly way to add more supported types ? Perhaps making this "if options['search']:" a separate function definition that could be used with super().

Any ideas?

@tiliv
Copy link
Contributor

tiliv commented Jun 9, 2014

Yeah that method is kind of a monster. I'll need to brainstorm the best way to deal with this.

The design goal was to allow the options to check the core Django field types (you'll notice the code doesn't actually check all of the built-in types either) because of the way the fields subclass one another. The built-in Django IP address field is, for example, just a CharField, so that means it behaves according to standard text ORM query types.

The netfields stuff is basically not subclassing anything but the base django class for Field, so it's falling through.

I can make it try to fall back to treating things as a char-type, but it would still be appropriate to support better field-type hooking for the sake of custom ORM query suffixes that this package can't know anything about.

I'll have to make a sprint on some of these recent tickets sometime this week. Sorry for the unfortunate difficulty, especially since there's not an obvious workaround without hacking that method.

tiliv added a commit that referenced this issue Jul 23, 2014
This should allow external customization of how field classes are
treated, particularly for external field from third-party apps, and
fields that we need to dynamically detect, such as the overlooked
``GenericIPAddressField``.

This closes #53 and address #49, although in the latter case, we may
still eventually want a way to register a field type “category” into
the dictionary with a set of trailing ORM query bits that can be
applied to support unknown extensions to the query language.
@tiliv tiliv added this to the 1.0 milestone Jul 23, 2014
@tiliv
Copy link
Contributor

tiliv commented Jan 9, 2015

I'll treat this as closed for now on account of the closed #53. Allowing custom queryset language is still of interest to me, which may lead me to reference this field type again in the future.

@tiliv tiliv closed this as completed Jan 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant