Hello everybody,
I'm using v. 2.0.
I've got a class configured as follow:
"ALTER CLASS V superclass ORestricted"
"ALTER CLASS TEST custom onCreate.identityType=role"
"ALTER CLASS TEST custom onCreate.fields=_allowDelete,_allowUpdate"
Everything works as supposed! If I insert a new record _allowDele
Hi Erik,
I would be disappointed if FULLTEXT indexing engine will be
discontinued, since there are some cases where I think it's still usefull.
Such as your case.
I would create a FULLTEXT index in this way:
create index Vlocation on V (location) FULLTEXT METADATA {
"indexRadix" : true,
Thanks Andrey.
It is added:
https://github.com/orientechnologies/orientdb/issues/3442
-Colin
On Thursday, January 22, 2015 at 2:37:42 AM UTC-6, Andrey Lomakin wrote:
>
> Hi,
> It is a bug, could you add issue ?
>
> On Wed, Jan 21, 2015 at 6:47 PM, Colin >
> wrote:--
> Best regards,
> Andrey L
Hi Riccardo,
Thanks for your response. I've worked with fulltext before but the results
in this case were poor. See below. Also, note that fulltext is expected to
be removed in next release.
https://groups.google.com/d/msg/orient-database/yroAgjsFpaI/oaaDAItM8mQJ
select location from geo where
long clusterId = odb.getClusterIdByName(className);
String reqS = "select * from "+className+" where @rid >
#"+Log.toString(qd.clusterId)+":"+Long.toString(CurrentHighRecordID);
(example: reqS = "select * from testdb where @rid > #7:436")
I have a structure that polls the orientdb 1.7 database a
So I had a breakthrough that gives me exactly what I'm looking for:
select *, out('identified') as identities from user fetchplan identities:1
Is there any reason why this type of query is a *bad idea*?
Geoff
On Wednesday, January 21, 2015 at 1:53:47 PM UTC-5, Geoff Goodman wrote:
>
> Hi Marc
You can use the simplest (but good) FULLTEXT index (
http://www.orientechnologies.com/docs/2.0/orientdb.wiki/FullTextIndex.html )
and use the index prefix to its default value (true). Tune also the
minWordLength as you need.
Then ask the query: SELECT FROM V WHERE location containsText "kansas"
C
Thanks for taking a look at this...appears to be a gap in ODB capability
but maybe I'm missing something. To clarify...
@Jing Yes I think the lucene results are as "designed" but not as
"desired". Note that the desired search is like "kansas%" not "%kansas%"
@Riccardo
Yes, prefix, "kansas%", st
Probably Erik has the need of indexing prefixes.
Just a question: does your prefixes have a fixed length or you want to be
able to perform fast searches on any possible substring of your fields?
Cheers,
Riccardo
2015-01-22 17:51 GMT+01:00 Jing Chen :
> Hi Erik,
>
> The Lucene result looks co
Hi Erik,
The Lucene result looks correct to me. Lucene index tokenizes your original
string and creates index. so
select location from geo where location lucene "kansas*"
should be the same as
select location from geo where location like "%kansas%"
Jing
On Thursday, January 22, 2015 at 8:4
Apparently OrientDB does not provide a performant "like" search capability.
Is that correct?
Here's an example.
*1) Returns desired results but 10x slow*
select from geo where location like "kansas%"
"kansas, united states"
"kansas city, kansas, united states"
"kansas city, missouri, united st
Hi Christofer,
Lightweight edges are a fundamental component in OrientDB Graph API. We
decided to disable it by default when you create new databases, because
most of the users have problem to get it working properly. So we decided to
put the "lightweight edges" as a feature to use at tuning time.
In OrientDB 2.0 release lightweight edges are disabled by default.
https://github.com/orientechnologies/orientdb/wiki/Lightweight-Edges
This breaks some of our application code, e.g.
com.orientechnologies.orient.core.command.traverse.OTraverse results now
containing edges.
getGraph().getVert
There is no check if validation is enabled or not in:
com.tinkerpop.blueprints.impls.orient.OrientElement#setPropertyInternal
Am Donnerstag, 22. Januar 2015 16:24:14 UTC+1 schrieb Fabian Renner:
>
> Hey guys,
>
>
> I do a massive insert in a orient graph db.
> I declared the massive insert inten
Hey guys,
I do a massive insert in a orient graph db.
I declared the massive insert intend and have values, that are "null" in my
to be imported records (NOT_NULL constraint is not set!!!)
Then I get this exception:
Exception in thread "main" java.lang.IllegalArgumentException: Property
val
I found a solution and seems to be working. Could you please validate it?
I'm afraid not to fool myself with the solution
select from (traverse * from #12:7 while (type= 'type of' or type is null))
The type is null clause is put because the vertices don't have the type
property.
On Thursday, J
Hello,
I'm new to OrientDB.
I have a simple OrientDB database with Classes and one type of relationship
between them.
Even if is one type of Edge we decided to use a 'type' attribute for the
Edge that differentiates between them.
Class0 --has a--> Class1
Class1 --has a--> Class2
Class1 --is a
Hi Andrey,
I only report what problems I have seen when I compile my project with the
OrientDB 2.0. Now, I need to go through one by one to see what is a
replacement, and how it should work in a new way. It would be great if you
could give me some idea about them.
About ODatabaseDocumentPool,
Ok, I was suspecting something like that, without being able to fix it.
Thanks for the tip!
> On 22 Jan 2015, at 07:48, Mo LOUKILI wrote:
>
> This is due to the plugin classloader since its parent class loader is the
> main Thread classloader.
>
> I would suggest to change the OServerPluginMa
Hi Luca,
I know these fields do not exist. This should only be an example what I'm
looking for for a better understanding (see my note above the config file
;)).
The Wiki is not really informative about complex Transformation :-(
I think its more efficient to store records in its own classes in
Hi,
It is a bug, could you add issue ?
On Wed, Jan 21, 2015 at 6:47 PM, Colin wrote:
> Hi Luca. Thanks for the reply.
>
> I understand that using a regular Edge that this is possible.
>
> Using the code in the EdgeIndexingTest.java link as an example of creating
> a unique index on a lightweigh
21 matches
Mail list logo
