Re: ertaggable not migrating
Re: ertaggable not migrating
- Subject: Re: ertaggable not migrating
- From: Joe Little <email@hidden>
- Date: Mon, 25 Jan 2010 15:32:42 -0800
Another hitch. Docs say to create a convenience method:
ERTaggableEntity provides entity-level tag management and fetching
methods. Typically you would provide a cover method from your entity
class to an instance of an ERTaggableEntity: public class Person
extends _Person { ... public static ERTaggableEntity taggableEntity()
{ return new ERTaggableEntity(Person.ENTITY_NAME); } }
So.. when I define
public static ERTaggableEntity taggableEntity() {
return new ERTaggableEntity(Company.ENTITY_NAME);
}
I get an error since Company.ENTITY_NAME returns a string where as the
ERTaggableEntity expects an EOEntity in the constructor. However,
nothing else seems to work there either. Another point where I must be
doing something wrong.
On Mon, Jan 25, 2010 at 2:54 PM, Joe Little <email@hidden> wrote:
> I wanted a to-many relationship for attachments on multiple entities
> (journals, payments,invoices, whatnot). In the end, I added that one
> line model dependency and it work. My model defines an entity called
> FileAttachment, which itself is modeled as a to-many for multiple
> other entities. FileAttachment has only the to-one relationship to
> ERAttachment as it seemingly requires based on what's documented. This
> may add a little work in creating an extra entity before uploads can
> happen, but it cleanly allows the two-many that I need.
>
> On Mon, Jan 25, 2010 at 1:58 PM, Mike Schrag <email@hidden> wrote:
>> sketchy.
>>
>> In your model, it has a to-one relationship to ERAttachment, right? it should have figured that out automagically and not even required ERAttachment declared explicitly, though it's generally a good thing to do anyway, since an explicit declaration defines the version #.
>>
>> On Jan 25, 2010, at 4:56 PM, Joe Little wrote:
>>
>>> Never mind my last comment. Yes, I put the below modelDependencies
>>> value in my primary migration, and it works now.
>>>
>>> On Mon, Jan 25, 2010 at 1:50 PM, Mike Schrag <email@hidden> wrote:
>>>> hmmm ... out of curiosity, in your ERAttachmentMigration subclass, if you
>>>> add the method:
>>>>
>>>>
>>>>
>>>> @Override
>>>> public NSArray<ERXModelVersion> modelDependencies() {
>>>> return new NSArray<ERXModelVersion>(new ERXModelVersion("ERAttachment",
>>>> 1));
>>>> }
>>>>
>>>> does that fix it? we should probably put that in there.
>>>> ms
>>>> On Jan 25, 2010, at 4:34 PM, Joe Little wrote:
>>>>
>>>> I'll do that. Also ran into trouble with ERAttachment. Doesn't it
>>>> auto-migrate in the table creation?
>>>>
>>>> Failed to execute 'ALTER TABLE FILE_ATTACHMENT ADD CONSTRAINT
>>>> FILE_ATTACHMENT_ATTACHMENT_ID_id_FK FOREIGN KEY (ATTACHMENT_ID)
>>>> REFERENCES ERAttachment (id) DEFERRABLE INITIALLY DEFERRED'
>>>> ERROR: relation "erattachment" does not exist
>>>>
>>>> "If you use Project Wonder migrations and migrateOnStartup, then the
>>>> ERAttachment tables will be automatically created for you on the first
>>>> launch. If you do not, then you can either manually execute the
>>>> .migration SQL scripts that are in the Resources folder (execute them
>>>> in numeric order), or you can open the EOModel and generate SQL for
>>>> your particular database."
>>>>
>>>> I definitely have the migrations running as that's how I'm building my
>>>> DB and adding ERTaggable.
>>>>
>>>> On Mon, Jan 25, 2010 at 1:22 PM, Mike Schrag <email@hidden> wrote:
>>>>
>>>> i honestly don't know why we don't just tell you this outright rather than
>>>> make you visually diff the two ... seems like something these new-fangled
>>>> computational machines would be good at. feel free to log a jira on that.
>>>>
>>>> ms
>>>>
>>>> On Jan 25, 2010, at 4:16 PM, Joe Little wrote:
>>>>
>>>> doh.. didn't see that when checking the two.
>>>>
>>>> On Mon, Jan 25, 2010 at 12:54 PM, Mike Schrag <email@hidden>
>>>> wrote:
>>>>
>>>> you can see from the two connection dicts what the diff is ...
>>>> AffiliateEOModel explicitly declares a plugin name while ERTaggable does
>>>> not. Just set a global override for plugin and it should fix your problem.
>>>>
>>>> ms
>>>>
>>>> On Jan 25, 2010, at 3:44 PM, Joe Little wrote:
>>>>
>>>> I'm getting this error,
>>>>
>>>> A fatal exception occurred: The connection dictionaries for ERTaggable
>>>>
>>>> and AffiliateEOModel have the same URL and username, but the
>>>>
>>>> connection dictionaries are not equal. Check your connection
>>>>
>>>> dictionaries carefully! This problem is often caused by jdbc2Info not
>>>>
>>>> matching between the two. One fix for this is to set
>>>>
>>>> ERTaggable.removeJdbc2Info=true and
>>>>
>>>> AffiliateEOModel.removeJdbc2Info=true in your Properties file.
>>>>
>>>> (ERTaggable={password = ""; username = "postgres"; URL =
>>>>
>>>> "jdbc:postgresql://localhost/affiliates"; }; and
>>>>
>>>> AffiliateEOModel={driver = "org.postgresql.Driver"; plugin =
>>>>
>>>> "PostgresqlPlugIn"; password = ""; username = "postgres"; URL =
>>>>
>>>> "jdbc:postgresql://localhost/affiliates"; })
>>>>
>>>> I've also put those two properties in the Properties file without
>>>>
>>>> help. I've defined my database via Properties as well:
>>>>
>>>> dbConnectURLGLOBAL=jdbc:postgresql://localhost/affiliates
>>>>
>>>> dbConnectUserGLOBAL=postgres
>>>>
>>>> dbConnectPasswordGLOBAL=
>>>>
>>>> Has someone seen this before and can suggest what the answer was?
>>>>
>>>> _______________________________________________
>>>>
>>>> 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