You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Matt Warnock <mw...@ridgecrestherbals.com> on 2010/09/16 00:56:12 UTC
complex-alias; public tables have no entity
Running trunk (996145 under Debian with postgresql 8.3.
When I run, I get two kinds of warnings that I don't understand:
First off, there are 8 or so warnings like this:
2010-09-11 13:16:45,664 (main) [ ModelViewEntity.java:538:WARN ]
Conversion for complex-alias needs to be implemented for cache and
in-memory eval stuff to work correctly, will not work for alias:
statusDelay of view-entity ExampleStatusDetail
Second, when I start OFBiz on an EXISTING postgresql database, I get the
following kind of warning for EACH table in the database:
2010-09-15 16:45:31,900 (main) [ DatabaseUtil.java:385:WARN ]
Table named [public.CURRENCY_DIMENSION] exists in the database but has
no corresponding entity
I suspect the latter is some kind of mismatch between the "public"
schema and the tablename without the schema portion.
Should I be concerned about either of these kinds of warnings? I
googled them both, found they had been asked before, but could not find
any answers. Does anyone know?
--
Matt Warnock <mw...@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.
Re: Data migration (was Re: complex-alias; public tables have no
entity)
Posted by BJ Freeman <bj...@free-man.net>.
you may want top create a Jira on Migration and link it as related or
incorporates setup
https://issues.apache.org/jira/browse/OFBIZ-635
my short answer is I have been toying with the ideas of using
multi-tenant to create a new DB then a script would move all the data
from the default to the new db.
then using a different location for the new code created a new default
and connect to the multi-tenant db created before, then use tools to
compare the two for data and structure differences.
your testing can be done on both dbs till you satisfied with out
effecting production.
eventually this will create the migration data and steps need to be
done. you can do this by using more multi-tenant dbs to migrate and
check progress till the migration is complete.
Matt Warnock sent the following on 9/16/2010 6:01 PM:
> Hi all:
>
> Sorry for the length of this post, but I'm trying to get a handle on
> best practices for code updates, and want to make sure I understand the
> process. I envision that the upgrade process for a production database
> goes something like this:
>
> 1) Backup everything (code and DB), in case you have to roll back.
> 2) Do "svn info" and note OLD revision number (is it in DB at all?).
> 3) Do "svn up" and note NEW revision number.
> 4) Check the wiki page BJ cites below to see what DB changes are needed.
> 5) Build the new code, integrating local modifications.
> 7) Test like crazy, especially the DB migration services/changes.
> 8) Automate& test migration process with a copy of the production DB.
> 9) Roll out new DB and server, ready with fast "rollback" if needed.
> 10) Make sure that the business stays up and running.
>
> Whether this process is done weekly, monthly, or "as feasible" with
> trunk, or only every year or two between OOTB stable releases, the
> upgrade path is about the same, is it not? The only real difference is
> the number of database changes that might be needed, and the time frame
> for advance testing on the selected new code revision. Could there be
> data migration issues from one revision to an other within release 9.04,
> for example? I'm assuming that would be unlikely, at least.
>
> It seems like running one consistent production DB, under two different
> versions of OFBiz, is likely to be problematic. So the actual conversion
> of the production DB probably needs to be done overnight, if possible.
> As the newly-modified production database is used in practice, and
> diverges from the old-version backup, "rolling back" soon becomes
> increasingly painful (days of lost work), eventually becoming a
> non-option. Am I envisioning this correctly?
>
> David warned last week or so that the data migration page BJ cites below
> is manually updated, therefore not guaranteed to be 100% correct. It
> also seems to only contain changes to table structure, not to seed data.
> I assume that new code may depend not only on new table structure, but
> also on data types and distinctions defined in new, additional seed
> data.
>
> Thinking about that, I conclude that it would be really important to
> know, in a fully automated way, what differences exist in the entity
> definitions, or seed data content, between arbitrary revisions X and Y.
> Does such a tool exist? Or does the entity-check code run on startup
> somehow fully answer that need?
>
> If not, it occurs to me that if I do a pg_dump (or the equivalent in
> Derby) immediately after running "./ant run-install-seed" for two
> arbitrary versions of OFBiz, I should be able to "diff" the two
> resulting files and see *ALL* the changes to both table structure, and
> seed data. A little more munging of those results could yield a more
> meaningful result, like "In table XYZ, change field "ABC" from
> "char(25)" to "char(30)", or "add (or subtract) a row of seed data as
> follows:" Are there problems you see with such an approach (other than
> it is totally DB-specific, of course).
>
> Am I worrying too much? I'm not betting the farm on OFBiz today, but if
> all goes according to plan, I soon will be.
>
Data migration (was Re: complex-alias; public tables have no
entity)
Posted by Matt Warnock <mw...@ridgecrestherbals.com>.
Hi all:
Sorry for the length of this post, but I'm trying to get a handle on
best practices for code updates, and want to make sure I understand the
process. I envision that the upgrade process for a production database
goes something like this:
1) Backup everything (code and DB), in case you have to roll back.
2) Do "svn info" and note OLD revision number (is it in DB at all?).
3) Do "svn up" and note NEW revision number.
4) Check the wiki page BJ cites below to see what DB changes are needed.
5) Build the new code, integrating local modifications.
7) Test like crazy, especially the DB migration services/changes.
8) Automate & test migration process with a copy of the production DB.
9) Roll out new DB and server, ready with fast "rollback" if needed.
10) Make sure that the business stays up and running.
Whether this process is done weekly, monthly, or "as feasible" with
trunk, or only every year or two between OOTB stable releases, the
upgrade path is about the same, is it not? The only real difference is
the number of database changes that might be needed, and the time frame
for advance testing on the selected new code revision. Could there be
data migration issues from one revision to an other within release 9.04,
for example? I'm assuming that would be unlikely, at least.
It seems like running one consistent production DB, under two different
versions of OFBiz, is likely to be problematic. So the actual conversion
of the production DB probably needs to be done overnight, if possible.
As the newly-modified production database is used in practice, and
diverges from the old-version backup, "rolling back" soon becomes
increasingly painful (days of lost work), eventually becoming a
non-option. Am I envisioning this correctly?
David warned last week or so that the data migration page BJ cites below
is manually updated, therefore not guaranteed to be 100% correct. It
also seems to only contain changes to table structure, not to seed data.
I assume that new code may depend not only on new table structure, but
also on data types and distinctions defined in new, additional seed
data.
Thinking about that, I conclude that it would be really important to
know, in a fully automated way, what differences exist in the entity
definitions, or seed data content, between arbitrary revisions X and Y.
Does such a tool exist? Or does the entity-check code run on startup
somehow fully answer that need?
If not, it occurs to me that if I do a pg_dump (or the equivalent in
Derby) immediately after running "./ant run-install-seed" for two
arbitrary versions of OFBiz, I should be able to "diff" the two
resulting files and see *ALL* the changes to both table structure, and
seed data. A little more munging of those results could yield a more
meaningful result, like "In table XYZ, change field "ABC" from
"char(25)" to "char(30)", or "add (or subtract) a row of seed data as
follows:" Are there problems you see with such an approach (other than
it is totally DB-specific, of course).
Am I worrying too much? I'm not betting the farm on OFBiz today, but if
all goes according to plan, I soon will be.
--
Matt Warnock <mw...@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.
On Wed, 2010-09-15 at 17:39 -0700, BJ Freeman wrote:
> though I have seen the first one did not dig in since it did not effect
> what I was doing.
>
> second one says that there is no entity in the current version that
> matches your DB table.
> usually you will find the entity named old and a new entity will be used.
> if your running productions servers you need to check if it effects your
> current system. if so then you need to do a migration.
> also check
> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
>
> Matt Warnock sent the following on 9/15/2010 3:56 PM:
> > Running trunk (996145 under Debian with postgresql 8.3.
> >
> > When I run, I get two kinds of warnings that I don't understand:
> >
> > First off, there are 8 or so warnings like this:
> > 2010-09-11 13:16:45,664 (main) [ ModelViewEntity.java:538:WARN ]
> > Conversion for complex-alias needs to be implemented for cache and
> > in-memory eval stuff to work correctly, will not work for alias:
> > statusDelay of view-entity ExampleStatusDetail
> >
> > Second, when I start OFBiz on an EXISTING postgresql database, I get the
> > following kind of warning for EACH table in the database:
> >
> > 2010-09-15 16:45:31,900 (main) [ DatabaseUtil.java:385:WARN ]
> > Table named [public.CURRENCY_DIMENSION] exists in the database but has
> > no corresponding entity
> >
> > I suspect the latter is some kind of mismatch between the "public"
> > schema and the tablename without the schema portion.
> >
> > Should I be concerned about either of these kinds of warnings? I
> > googled them both, found they had been asked before, but could not find
> > any answers. Does anyone know?
> >
> >
Re: complex-alias; public tables have no entity
Posted by BJ Freeman <bj...@free-man.net>.
though I have seen the first one did not dig in since it did not effect
what I was doing.
second one says that there is no entity in the current version that
matches your DB table.
usually you will find the entity named old and a new entity will be used.
if your running productions servers you need to check if it effects your
current system. if so then you need to do a migration.
also check
https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
Matt Warnock sent the following on 9/15/2010 3:56 PM:
> Running trunk (996145 under Debian with postgresql 8.3.
>
> When I run, I get two kinds of warnings that I don't understand:
>
> First off, there are 8 or so warnings like this:
> 2010-09-11 13:16:45,664 (main) [ ModelViewEntity.java:538:WARN ]
> Conversion for complex-alias needs to be implemented for cache and
> in-memory eval stuff to work correctly, will not work for alias:
> statusDelay of view-entity ExampleStatusDetail
>
> Second, when I start OFBiz on an EXISTING postgresql database, I get the
> following kind of warning for EACH table in the database:
>
> 2010-09-15 16:45:31,900 (main) [ DatabaseUtil.java:385:WARN ]
> Table named [public.CURRENCY_DIMENSION] exists in the database but has
> no corresponding entity
>
> I suspect the latter is some kind of mismatch between the "public"
> schema and the tablename without the schema portion.
>
> Should I be concerned about either of these kinds of warnings? I
> googled them both, found they had been asked before, but could not find
> any answers. Does anyone know?
>
>
Re: complex-alias; public tables have no entity
Posted by Matt Warnock <mw...@ridgecrestherbals.com>.
Thanks Scott and BJ.
The first warning message appears to say that in-memory eval
functionality won't work, which is a bit unnerving. Not knowing what
that is, I have no way of knowing whether that breaks some ofbiz
functionality or not. If it's really only the caching, perhaps no big
deal. Are we saying that it may slow operations, but won't break them?
On the second one, I should have said that I am using localpostnew, and
my schema-name is in fact "public", the OOTB value. These warnings
don't appear in Derby, so I assume its a Postgresql difference.
Seems like maybe postgres is delivering the schema-qualified name, when
ofbiz expects the bare tablename, or something like that. I see no
problems OTHER than these 700+ error messages, but it doesn't seem like
ofbiz should complain about its own native tables...
--
Matt Warnock <mw...@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.
On Thu, 2010-09-16 at 14:54 +1200, Scott Gray wrote:
> Hi Matt,
>
> The first is just a warning that caching won't take place for complex view aliases because it hasn't been implemented yet, I can't tell you much more than that.
>
> For the second, what is the value of the schema-name attribute for your postgres datasource in entityengine.xml? OOTB it should be set to "public" and should prevent the other warnings you are seeing if it is set.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 16/09/2010, at 10:56 AM, Matt Warnock wrote:
>
> > Running trunk (996145 under Debian with postgresql 8.3.
> >
> > When I run, I get two kinds of warnings that I don't understand:
> >
> > First off, there are 8 or so warnings like this:
> > 2010-09-11 13:16:45,664 (main) [ ModelViewEntity.java:538:WARN ]
> > Conversion for complex-alias needs to be implemented for cache and
> > in-memory eval stuff to work correctly, will not work for alias:
> > statusDelay of view-entity ExampleStatusDetail
> >
> > Second, when I start OFBiz on an EXISTING postgresql database, I get the
> > following kind of warning for EACH table in the database:
> >
> > 2010-09-15 16:45:31,900 (main) [ DatabaseUtil.java:385:WARN ]
> > Table named [public.CURRENCY_DIMENSION] exists in the database but has
> > no corresponding entity
> >
> > I suspect the latter is some kind of mismatch between the "public"
> > schema and the tablename without the schema portion.
> >
> > Should I be concerned about either of these kinds of warnings? I
> > googled them both, found they had been asked before, but could not find
> > any answers. Does anyone know?
> >
> >
> > --
> > Matt Warnock <mw...@ridgecrestherbals.com>
> > RidgeCrest Herbals, Inc.
> >
> >
> >
>
Re: complex-alias; public tables have no entity
Posted by Scott Gray <sc...@hotwaxmedia.com>.
Hi Matt,
The first is just a warning that caching won't take place for complex view aliases because it hasn't been implemented yet, I can't tell you much more than that.
For the second, what is the value of the schema-name attribute for your postgres datasource in entityengine.xml? OOTB it should be set to "public" and should prevent the other warnings you are seeing if it is set.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 16/09/2010, at 10:56 AM, Matt Warnock wrote:
> Running trunk (996145 under Debian with postgresql 8.3.
>
> When I run, I get two kinds of warnings that I don't understand:
>
> First off, there are 8 or so warnings like this:
> 2010-09-11 13:16:45,664 (main) [ ModelViewEntity.java:538:WARN ]
> Conversion for complex-alias needs to be implemented for cache and
> in-memory eval stuff to work correctly, will not work for alias:
> statusDelay of view-entity ExampleStatusDetail
>
> Second, when I start OFBiz on an EXISTING postgresql database, I get the
> following kind of warning for EACH table in the database:
>
> 2010-09-15 16:45:31,900 (main) [ DatabaseUtil.java:385:WARN ]
> Table named [public.CURRENCY_DIMENSION] exists in the database but has
> no corresponding entity
>
> I suspect the latter is some kind of mismatch between the "public"
> schema and the tablename without the schema portion.
>
> Should I be concerned about either of these kinds of warnings? I
> googled them both, found they had been asked before, but could not find
> any answers. Does anyone know?
>
>
> --
> Matt Warnock <mw...@ridgecrestherbals.com>
> RidgeCrest Herbals, Inc.
>
>
>