[sqlalchemy] Re: Is inserting new data with column_mapped_collection inconsistent?
Allen Bierbaum wrote:
On Fri, May 16, 2008 at 4:54 PM, jason kirtland [EMAIL PROTECTED] wrote:
[..]
Anyway, I think this is a bit non-intuitive. What I propose instead
is that SA could automatically set the 'keyword' attribute of the Note
object as part of the process of assigning it to the mapped collection
dictionary. This way the insert could look more like:
item.notes['not-color'] = Note(value='blue')
and behind the scenes SA would call: new Note.keyword = 'not-color'
Any thoughts on this? Has anyone tried this in the past?
MappedCollection doesn't currently have a mismatch guard on __setitem__
(d[key] = val) or setdefault(), but easily could. There *is* a guard
protecting against item.notes = {'not-color': Note('color', 'blue')}, so
that machinery is available and applying it to the other setters is
straightforward.
Automatically setting the value for the attribute_ and column_mapped
dict collections would be pretty convenient and DRY. This is a great
time to integrate that feature, if you want to try your hand at putting
together a patch and tests. If it's not too disruptive to existing
users it could slide right in as a new feature of 0.5.
I would be more then happy to look into this (I already have), but I
think my skills aren't quite up to the challenge. Could you point me
in the general direction?
You might start looking at _convert here:
http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/sqlalchemy/orm/collections.py#L1402
It could be the case that that logic can be combined with the proposed
value-setting logic and used for @converter, __setitem__, etc.
The basic MappedCollection would probably have a default implementation
that does no attribute setting, being as there's no reasonable way to
intuit a reverse operation given only an arbitrary keying function
lambda. The attribute_ and column_mapped_ front ends would set up their
own implementations of the function that does key checking plus
attribute setting behavior.
On a related note, I think it would be good to make this behavior come
through a user customizable callback method that takes the index value
and the newly assigned class item as values. This would allow users
to add more automatic behavior that may be needed.
For example I my current relationship is actually like this:
'input_vars' : relation(Var, primaryjoin = and_(script_table.c.id
== var_table.c.script_id,
var_table.c.input_output_type == 0),
collection_class=column_mapped_collection(var_table.c.name)),
So I would want to not only set the name automatically based on the
key, but I would want to set the input_output_type to 0 in this case.
Something like this would be good.
def input_cb(key, item):
item.name = key
item.input_output_type = 0
If the setup I described above works out, this kind of thing could be
had pretty much for free.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Is inserting new data with column_mapped_collection inconsistent?
On Fri, May 16, 2008 at 4:54 PM, jason kirtland [EMAIL PROTECTED] wrote:
[..]
Anyway, I think this is a bit non-intuitive. What I propose instead
is that SA could automatically set the 'keyword' attribute of the Note
object as part of the process of assigning it to the mapped collection
dictionary. This way the insert could look more like:
item.notes['not-color'] = Note(value='blue')
and behind the scenes SA would call: new Note.keyword = 'not-color'
Any thoughts on this? Has anyone tried this in the past?
MappedCollection doesn't currently have a mismatch guard on __setitem__
(d[key] = val) or setdefault(), but easily could. There *is* a guard
protecting against item.notes = {'not-color': Note('color', 'blue')}, so
that machinery is available and applying it to the other setters is
straightforward.
Automatically setting the value for the attribute_ and column_mapped
dict collections would be pretty convenient and DRY. This is a great
time to integrate that feature, if you want to try your hand at putting
together a patch and tests. If it's not too disruptive to existing
users it could slide right in as a new feature of 0.5.
I would be more then happy to look into this (I already have), but I
think my skills aren't quite up to the challenge. Could you point me
in the general direction?
On a related note, I think it would be good to make this behavior come
through a user customizable callback method that takes the index value
and the newly assigned class item as values. This would allow users
to add more automatic behavior that may be needed.
For example I my current relationship is actually like this:
'input_vars' : relation(Var, primaryjoin = and_(script_table.c.id
== var_table.c.script_id,
var_table.c.input_output_type == 0),
collection_class=column_mapped_collection(var_table.c.name)),
So I would want to not only set the name automatically based on the
key, but I would want to set the input_output_type to 0 in this case.
Something like this would be good.
def input_cb(key, item):
item.name = key
item.input_output_type = 0
'input_vars' : relation(Var, primaryjoin = and_(script_table.c.id ==
var_table.c.script_id,
var_table.c.input_output_type == 0),
collection_class=column_mapped_collection(var_table.c.name,
set_cb=input_cb)),
Any thoughts and/or pointers on how to implement this?
-Allen
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Is inserting new data with column_mapped_collection inconsistent?
Allen Bierbaum wrote:
I have just started using column_mapped_collections.
(http://www.sqlalchemy.org/docs/04/mappers.html#advdatamapping_relation_collections_dictcollections
I must say, these are very powerful and extremely nice when reading
data. But I have run into one thing that seems confusing when it
comes to creating new objects in a session. Namely, it is possible to
add data to the mapped dictionary in such a way that the data
structure is inconsistent and not what it would be when reading the
same data back.
Using the example from the documentation as a start:
mapper(Item, items_table, properties={
'notes': relation(Note,
collection_class=column_mapped_collection(notes_table.c.keyword)),
})
# ...
item = Item()
item.notes['color'] = Note('color', 'blue') # Set keyword attribute to
'color'
print item.notes['color']
Everything is good here, but what if I did it this way instead
item.notes['not-color'] = Note('color', 'blue')
This last line is the problem because it has inserted a link to a new
Note that has a keyword of
'color' but is showing up in the dictionary as 'not-color'. If we
flush all of this and reload from the database using a query, there
will be no 'not-color' entry in the database.
Anyway, I think this is a bit non-intuitive. What I propose instead
is that SA could automatically set the 'keyword' attribute of the Note
object as part of the process of assigning it to the mapped collection
dictionary. This way the insert could look more like:
item.notes['not-color'] = Note(value='blue')
and behind the scenes SA would call: new Note.keyword = 'not-color'
Any thoughts on this? Has anyone tried this in the past?
MappedCollection doesn't currently have a mismatch guard on __setitem__
(d[key] = val) or setdefault(), but easily could. There *is* a guard
protecting against item.notes = {'not-color': Note('color', 'blue')}, so
that machinery is available and applying it to the other setters is
straightforward.
Automatically setting the value for the attribute_ and column_mapped
dict collections would be pretty convenient and DRY. This is a great
time to integrate that feature, if you want to try your hand at putting
together a patch and tests. If it's not too disruptive to existing
users it could slide right in as a new feature of 0.5.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
