joining entities may have some overhead. Is it prohibitive in absolute terms?
On Sat, Mar 14, 2009 at 12:29 AM, Rui António da Cruz Pereira
wrote:
> The two entities resolves the problem, but adds some overhead (the queries
> can be really big). The views doesn't work for me, as the queries are
>
The two entities resolves the problem, but adds some overhead (the
queries can be really big). The views doesn't work for me, as the
queries are dynamically generated, taken in consideration a determinate
topology.
Noble Paul നോബിള് नोब्ळ् wrote:
have one root which just does a "select id f
It may be easier to make a view in the database and index the view.
Databases have good tools for that.
wunder
On 3/13/09 2:46 AM, "Rui António da Cruz Pereira"
wrote:
> I have queries with outer joins defined in some entities and for the
> same root object I can have two or more lines with dif
have one root which just does a "select id from Table1 "
.Then have a child entiy which does all the joins and return all other
columns for that 'id'.
On Fri, Mar 13, 2009 at 5:10 PM, Rui António da Cruz Pereira
wrote:
> I thought that I could remove the uniqueKey in Solr and then have more tha
I thought that I could remove the uniqueKey in Solr and then have more
that one document with the same id, but then I don't know if in
delta-imports the documents outdated or deleted are updated (updated
document is added and then we would have the outdated and the updated
document in the index
it is not very clear to me on how it works
probably you can put in the queries here.
you can do all the joins in the db in one complex query and use that
straightaway in an entity. You do not have to do any joins inside DIH
itself
On Fri, Mar 13, 2009 at 4:47 PM, Rui António da Cruz Pereira
wro
