Re: ERXMigrationTable.newColumn does not set default value
Re: ERXMigrationTable.newColumn does not set default value
- Subject: Re: ERXMigrationTable.newColumn does not set default value
- From: David Avendasora <email@hidden>
- Date: Tue, 22 Apr 2008 13:04:25 -0400
Okay, I'll get the ability to read the
"er.extensions.eoattribute.default" along with the simpler "Default"
from the userInfo dictionary setup in the ERXMicrosoftPlugIn like it
is in the FrontbasePlugIn, and then hand it off you you and Chuck for
review.
Out of curiosity, what does the defaultValue parameter as defined in
the Wonder API for ERXMigrationsTable.newXxxxColumn() do?
For example: http://webobjects.mdimension.com/wonder/api/er/extensions/migration/ERXMigrationTable.html#newStringColumn(java.lang.String, int, boolean, java.lang.String)
Thanks!
Dave
On Apr 22, 2008, at 12:52 PM, Mike Schrag wrote:
Defaults are not covered by the spec at all ... Wonder migrations
set the default value into the "er.extensions.eoattribute.default"
attribute in the attribute's userInfo during the migration process,
so that's the one you should use. FrontBasePlugIn has an example of
this.
ms
On Apr 22, 2008, at 11:45 AM, David Avendasora wrote:
Hey Mike,
I'm trying to add this to the ERXMicrosoftPlugin. I've added a
MicrosoftExpression Inner Class, and copied over much of what was
in the FrontbaseExpression IC with some modifications, but it looks
like where it's looking for the default value is from the UserInfo
dictionary in the model as opposed to the default value from the
Migration class.
Is the userInfo dictionary the place to set defaults, and if so,
what does the default do in the Migration class?
Thanks!
Dave
On Apr 10, 2008, at 8:50 AM, Mike Schrag wrote:
I lied anyway ... I DID actually add it to PGSQL, but I was
looking in the same wrong place that you were. FB PlugIn has two
inner classes (the schemasync and the expression). That method is
actually in expression, not in sync, so when I looked in PG, I
didn't see it. However, it IS in PGExpession. So I suspect your
problems with defaults not working are due to 5.4. I'll have to
check this for the next WO version, but I SUSPECT it works
properly ...
ms
On Apr 10, 2008, at 8:38 AM, Mike Schrag wrote:
The statment is built by a call of
EOSchemaSynchronizationFactory._columnCreationClauseForAttribute
method which calls - in my case
I take it (based on the class name you're referencing here) that
you're using WO 5.4.x? The problems I've discussed previously
with respect to SQL generation in 5.4.x make this not worth
trying to fix on your 5.4.x build until the next WO release ...
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden