Hi Angelo, I don’t really have anything constructive to add to what others have already said. I’ve always had a app user database login, separate from the table owner(s). (This allows you to restrict what the app can do, such as only insert into audit tables.) Then, in Oracle anyway, you can create a synonym in the app user schema to point to the table, no matter which schema it’s in. Another option, if they’re all in a single "table owner" schema, is you can set a default schema name for the app user.
You have the flexibility to get as custom as you need to. For example, I had another application once where the table names actually had to be changed dynamically (not my design!). The schema for most of the tables was repeated over a hundred times, once for each customer, with a different suffix. Instead of modeling it over and over I intervened in the SQL generation to substitute the currently active customer suffix. The result hid all of the complexity nicely. Anyway, good luck with your project. :-) Regards, Mark On May 4, 2015, at 7:04 PM, Ângelo Andrade Cirino <aacir...@gmail.com> wrote: > Hi Mark, > > I thought about it too, but it would be a non-standard solution, since each > developer could use a name for the property. To be more precise, I abandoned > this idea after working to change the FrontBase plug-in and SQLHelper to use > EOSchemaSynchronizationFactory. The code that will use the schema name > property is so deep down in the Wonder framework that using a non-standard > property name could lead to serious problems. > > What’s your opinion on the validity of adding the schema name as an explicit > property for entities? Is it worth the effort? > > Angelo > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
