populate entitylist/set
lekmalek
Hi,
Attached is a patch that allows the '_initial' Entity notation for
EntityList and EntitySet.
example:
class Foo(E.Entity):
name = f.string()
_key(name)
_initial = [
("foo1",),
("foo2",),
]
class Bar(E.Entity):
name = f.string()
foos = f.entity_list("Foo")
_initial = [
("bar1", [("foo2",), ("foo1",)]),
("bar2", [("foo1",), ("foo2",)]),
]
i don't really know where to put the tests though
hope it helps
lekma
Matthew Scott
Matthew Scott
The branch is ready for you to review; see http://schevo.org/ticket/62#comment:2
for details.
I'll merge it as soon as you give me the go-ahead.
Thanks again for the patch!
On Sep 5, 1:13 pm, lekmalek <lekma...@gmail.com> wrote:
> populate_set_list_transaction.py.diff
> 3KDownload
lekmalek
Matthew Scott <gldn...@gmail.com> wrote:
>
> Lekma,
>
> The branch is ready for you to review; see
> http://schevo.org/ticket/62#comment:2 for details.
>
> I'll merge it as soon as you give me the go-ahead.
it seems great from where i sit, go ahead :)
>
> Thanks again for the patch!
thank _you_ for fixing it and merging
on a side note:
do you think it could be possible to have the same notation for the
default attribute of Entity, EntityList, EntitySet?
something like:
foo = f.entity("Foo", default=("bar2",))
or
foos = f.entity_list("Foo", default=[("bar2",),("bar1",)])
i had a look at transaction.py and field.py but that seems much more
difficult... :(
thanks again
lekma
Matthew Scott
> on a side note:
> do you think it could be possible to have the same notation for the
> default attribute of Entity, EntityList, EntitySet?
>
> something like:
> foo = f.entity("Foo", default=("bar2",))
> or
> foos = f.entity_list("Foo", default=[("bar2",),("bar1",)])
+1 for that in terms of being nice for symmetry, and if you have a
real use case for it please let us know and that will make it a +2.
I'll go ahead an merge ticket 62 to trunk, and open another ticket for
this. I'm sure we can generalize the code that _Populate uses so that
some of that logic could be used for field default values.
A question: for "foo = f.entity('Foo', default=('bar2',))", what
would be the default value for the 'foo' field if the 'bar2' Foo was
not found? Would it be UNASSIGNED, or should it raise an exception?
Patrick O'Brien
A question: for "foo = f.entity('Foo', default=('bar2',))", what
would be the default value for the 'foo' field if the 'bar2' Foo was
not found? Would it be UNASSIGNED, or should it raise an exception?
I feel pretty strongly that it should raise an exception.
Patrick K. O'Brien
Orbtech http://www.orbtech.com
Schevo http://www.schevo.org
lekmalek
Matthew Scott <gldn...@gmail.com> wrote:
>
> On Sep 6, 7:58 am, lekmalek <lekma...@gmail.com> wrote:
> > on a side note:
> > do you think it could be possible to have the same notation for the
> > default attribute of Entity, EntityList, EntitySet?
> >
> > something like:
> > foo = f.entity("Foo", default=("bar2",))
> > or
> > foos = f.entity_list("Foo", default=[("bar2",),("bar1",)])
>
> +1 for that in terms of being nice for symmetry, and if you have a
> real use case for it please let us know and that will make it a +2.
no, i don't have any real use case scenario in mind (I'm still trying to
learn schevo, you know), but, given the _initial notation I've come
familiar to, it seemed only natural to write it the same way (well, up
to the point i realized it was not working, :)).
>
> I'll go ahead an merge ticket 62 to trunk, and open another ticket for
> this. I'm sure we can generalize the code that _Populate uses so that
> some of that logic could be used for field default values.
>
> A question: for "foo = f.entity('Foo', default=('bar2',))", what
> would be the default value for the 'foo' field if the 'bar2' Foo was
> not found? Would it be UNASSIGNED, or should it raise an exception?
it should definitely raise, well at least i think so.
atm, in fact, if you do: foo = f.entity("Foo", default=("bar2",)), it
doesn't raise an exception, which i also think it should do (the
default value is just applied).
>
>
>
> >
Matthew Scott
On Sep 7, 3:15 am, lekmalek <lekma...@gmail.com> wrote:
> On Thu, 06 Sep 2007 07:00:38 -0700
>
> Matthew Scott <gldns...@gmail.com> wrote:
>
> > On Sep 6, 7:58 am, lekmalek <lekma...@gmail.com> wrote:
> > > foo = f.entity("Foo", default=("bar2",))
> > > or
> > > foos = f.entity_list("Foo", default=[("bar2",),("bar1",)])
>
> > +1 for that in terms of being nice for symmetry, and if you have a
> > real use case for it please let us know and that will make it a +2.
>
> no, i don't have any real use case scenario in mind (I'm still trying to
> learn schevo, you know), but, given the _initial notation I've come
> familiar to, it seemed only natural to write it the same way (well, up
> to the point i realized it was not working, :)).
If you are learning Schevo, and you tried it, and it didn't work as
you expected it should based on the _initial/_sample syntax, and it
also didn't give you an error, then I think that's reason enough for
us to implement it :)
I created a ticket for this at http://schevo.org/ticket/65
> > A question: for "foo = f.entity('Foo', default=('bar2',))", what
> > would be the default value for the 'foo' field if the 'bar2' Foo was
> > not found? Would it be UNASSIGNED, or should it raise an exception?
>
> it should definitely raise, well at least i think so.
> atm, in fact, if you do: foo = f.entity("Foo", default=("bar2",)), it
> doesn't raise an exception, which i also think it should do (the
> default value is just applied).
I agree with you and Pat about raising an exception -- seems silly
that I even mentioned UNASSIGNED now.
I think the time to raise the exception is when creating a transaction
that uses the default value, such as Create transactions.
The problem with raising an exception while loading the schema is that
the schema has no idea if ('bar2',) will exist in db.Foo at all. It
could be something where it isn't even in the _initial data -- in that
case, you wouldn't be able to create whatever entity that field was
specified in until that default value existed, but if that's what the
schema designer desires, then that is what he or she desires. :-)
lekmalek
It makes sense too me, but maybe I misunderstood the goal of the
'default' attribute.
There's an other attribute of fields that I seem to have problems with,
namely 'readonly'. If you put a field read-only, you can't put a value
in the field at creation time (except if you lift the read-only
restriction in _setup()), and then, ironically, it complains that
the value is required. That kinda seems illogical to me. A 'readonly'
field, should only be read-only for update, shouldn't it?
It'd be also nice to hear what other people might think about that,
cause i feel like I'm steering (maybe that's too strong a word) schevo
in a direction where it was not intended to go. If that is the case,
please tell me.
thanks for all the help
lekma
>
>
>
>
> >
Patrick O'Brien
It makes sense too me, but maybe I misunderstood the goal of the
'default' attribute.
I don't think you've misunderstood the goal of 'default'. All it does is prepopulate the field for the Create transaction. And having symmetry with the way initial and sample values works would be a good thing.
There's an other attribute of fields that I seem to have problems with,
namely 'readonly'. If you put a field read-only, you can't put a value
in the field at creation time (except if you lift the read-only
restriction in _setup()), and then, ironically, it complains that
the value is required. That kinda seems illogical to me. A 'readonly'
field, should only be read-only for update, shouldn't it?
If you specify 'readonly' at the general field level in the schema (as part of the Entity class definition) then it will apply to *all* transactions that include that field. If you want it to be 'readonly' for Update transactions alone, then you can set it to 'readonly' in the setup for Update. That's the most common use case.
But you might want to automatically set some value as part of Create, and allow the user to see what you've automatically set the value to, without allowing them to change it. If you want the value to be UNASSIGNED and readonly then you'll also need to set 'required' to False. The 'required' attribute doesn't mean that the user has to supply the value, just that something needs to assign a value to the field and the value can't be UNASSIGNED.
Are you seeing behavior other than what I've just described?
It'd be also nice to hear what other people might think about that,
cause i feel like I'm steering (maybe that's too strong a word) schevo
in a direction where it was not intended to go. If that is the case,
please tell me.
All your suggestions have been good ones, imo. Keep 'em coming. ;-)
lekmalek
Attached is a "working" patch that implements the '_initial' notation
for 'default' attribute on Entity/EntityList/EntitySet fields. It needs
_careful_ review, since it is quite invasive (and I'm far from being
sure of the choices I made):
- I took out resolve() from Populate._execute() and made it a module
function (should it stay in transaction?).
- I changed its signature by adding a db argument.
- I changed the behaviour of Populate._execute(), thus of '_initial',
by raising an exception, if an entity is not found, in resolve().
- I wonder if the arguments I pass to resolve() during Create.__init__()
are the correct/expected ones.
hope it helps
lekma
Matthew Scott
> Attached is a "working" patch that implements the '_initial' notation
> for 'default' attribute on Entity/EntityList/EntitySet fields. It needs
> _careful_ review, since it is quite invasive (and I'm far from being
> sure of the choices I made):
Lekma,
I've applied your patch, with some minor mods, to the branch for
http://schevo.org/ticket/65
Thanks for submitting it so quickly!
Pat,
One thing we need to look at carefully before we merge this is the
_ignore_defaults keyword argument I added to Create -- see
http://schevo.org/ticket/65#comment:5
The problem this introduced is that I had to change two unit tests to
account for this. It's no longer acceptable to create a custom
t_create method by using:
@extentmethod
def t_create(extent):
return E.Whatever._Create()
Instead, you have to accept and pass through keyword args:
@extentmethod
def t_create(extent, **kw):
return E.Whatever._Create(**kw)
Should we insist that one pass **kw through (or at the very least, the
_ignore_defaults argument) to Create transactions?
Or should we figure out another way to get around this issue without
having to pass in such an argument?
lekmalek
Matthew Scott <gldn...@gmail.com> wrote:
>
> On Sep 9, 6:37 am, lekmalek <lekma...@gmail.com> wrote:
> > Attached is a "working" patch that implements the '_initial'
> > notation for 'default' attribute on Entity/EntityList/EntitySet
> > fields. It needs _careful_ review, since it is quite invasive (and
> > I'm far from being sure of the choices I made):
>
> Lekma,
>
> I've applied your patch, with some minor mods, to the branch for
> http://schevo.org/ticket/65
>
> Thanks for submitting it so quickly!
>
> Pat,
>
one minor cosmetic change ;-)
--- schevo/transaction.py.orig 2007-09-12 11:35:19.000000000 +0200
+++ schevo/transaction.py 2007-09-12 12:05:32.000000000 +0200
@@ -813,7 +813,7 @@
raise TypeError(msg)
value = lookup_extent.findone(**kw)
if value is None:
- raise ValueError('no entity %s found in extent %s' %
+ raise ValueError('no entity %s found in %s' %
(kw, lookup_extent))
return value
Matthew Scott
Got it in there...
After figuring out how to not require the _ignore_defaults abomination
that I temporarily introduced, and after writing some documentation
about initial/sample data and default field values, ticket 65 is now
merged and closed.