Github user asfgit commented on the issue:
https://github.com/apache/madlib/pull/325
Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/madlib-pr-build/699/
---
Github user iyerr3 commented on the issue:
https://github.com/apache/madlib/pull/325
The constraint with this strategy is that the IC/DC has to be run by a
super-user.
Additionally, it won't test the deployment of MADlib in the actual user DB.
---
Github user orhankislal commented on the issue:
https://github.com/apache/madlib/pull/325
Another alternative is to integrate the madlib deployment into the IC/DC.
What I mean is similar to how PostGIS runs its unit tests. IC/DC creates a
temporary database/schema, deploys the MADlib
Github user orhankislal commented on the issue:
https://github.com/apache/madlib/pull/325
> Also note: madpack is supposed to drop the file-specific schema after
executing each file (see function _execute_per_module_install_dev_check_algo).
Hence, common table names in independent
Github user iyerr3 commented on the issue:
https://github.com/apache/madlib/pull/325
> > * Use a function-specific name (`"pagerank_vertex"`) instead of a
generic name with (`"vertex"`) no drop by in the beginning.
>
> This seems doesn't solve the potential conflict with user
Github user jingyimei commented on the issue:
https://github.com/apache/madlib/pull/325
@iyerr3
> I'm getting confused here, so maybe an example would help.
>
> My understanding of @orhankislal 's comment was that say `page_rank` and
`bfs` both use the same table
Github user iyerr3 commented on the issue:
https://github.com/apache/madlib/pull/325
I'm getting confused here, so maybe an example would help.
My understanding of @orhankislal 's comment was that say `page_rank` and
`bfs` both use the same table called "vertex" then we will
Github user jingyimei commented on the issue:
https://github.com/apache/madlib/pull/325
@iyerr3 The install-check schema is by module, and we may have multiple
files for one module.
For your proposed solution, what do you expect in the single source of
table creation? Do
Github user iyerr3 commented on the issue:
https://github.com/apache/madlib/pull/325
> I agree, this is not a great solution. Casting the operators makes it
especially awkward to use. However, we have to consider the following case. If
a module has multiple test files like `graph`
Github user orhankislal commented on the issue:
https://github.com/apache/madlib/pull/325
I agree this is not a great solution. Casting the operators makes it
especially awkward to use. However, we have to consider the following case. If
a module has multiple test files like `graph`
Github user iyerr3 commented on the issue:
https://github.com/apache/madlib/pull/325
Wouldn't we only need to remove the first drop table call? The subsequent
ones should pick the correct one, isn't it?
I like the convenience of not having to provide the schema name in the
Github user orhankislal commented on the issue:
https://github.com/apache/madlib/pull/325
@iyerr3 @jingyimei I'll put the following in the commit message before
merging.
This commit fixes the following potential issue.
1. User deploys MADlib on the schema `madlib1`.
2.
Github user jingyimei commented on the issue:
https://github.com/apache/madlib/pull/325
> @orhankislal Since this is a really big change, could you please add more
info in the commit on why this change is necessary and the best available
solution?
+ 1
---
Github user iyerr3 commented on the issue:
https://github.com/apache/madlib/pull/325
@orhankislal Since this is a really big change, could you please add more
info in the commit on why this change is necessary and the best available
solution?
---
14 matches
Mail list logo
