[jira] [Commented] (ATLAS-1019) Add an API to find entities with the given traits with MetadataService
[ https://issues.apache.org/jira/browse/ATLAS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15374460#comment-15374460 ] Satish Duggana commented on ATLAS-1019: --- I meant about having an API in MetadataService, updated JIRA summary with that. Pl let me know if there is an existing API to do that. > Add an API to find entities with the given traits with MetadataService > -- > > Key: ATLAS-1019 > URL: https://issues.apache.org/jira/browse/ATLAS-1019 > Project: Atlas > Issue Type: Improvement >Reporter: Satish Duggana > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ATLAS-1019) Add an API to find entities with the given traits with MetadataService
[ https://issues.apache.org/jira/browse/ATLAS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satish Duggana updated ATLAS-1019: -- Summary: Add an API to find entities with the given traits with MetadataService (was: Add an API to find entities with the given traits with MetadatService) > Add an API to find entities with the given traits with MetadataService > -- > > Key: ATLAS-1019 > URL: https://issues.apache.org/jira/browse/ATLAS-1019 > Project: Atlas > Issue Type: Improvement >Reporter: Satish Duggana > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ATLAS-1019) Add an API to find entities with the given traits with MetadatService
[ https://issues.apache.org/jira/browse/ATLAS-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satish Duggana updated ATLAS-1019: -- Summary: Add an API to find entities with the given traits with MetadatService (was: Add an API to find entities with the given traits) > Add an API to find entities with the given traits with MetadatService > - > > Key: ATLAS-1019 > URL: https://issues.apache.org/jira/browse/ATLAS-1019 > Project: Atlas > Issue Type: Improvement >Reporter: Satish Duggana > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ATLAS-1018) Add an API to return deleted entity instead of returning guid of the deleted entity
Satish Duggana created ATLAS-1018: - Summary: Add an API to return deleted entity instead of returning guid of the deleted entity Key: ATLAS-1018 URL: https://issues.apache.org/jira/browse/ATLAS-1018 Project: Atlas Issue Type: Improvement Reporter: Satish Duggana -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ATLAS-1017) Sequence support to generate unique numbers(can be monotonic) like Phoenix by suing the underlying types storage engine.
Satish Duggana created ATLAS-1017: - Summary: Sequence support to generate unique numbers(can be monotonic) like Phoenix by suing the underlying types storage engine. Key: ATLAS-1017 URL: https://issues.apache.org/jira/browse/ATLAS-1017 Project: Atlas Issue Type: Improvement Reporter: Satish Duggana Sequence support to generate unique numbers(can be monotonic) like Phoenix by using the underlying types storage engine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ATLAS-1016) Support for composite unique attributes for a type.
Satish Duggana created ATLAS-1016: - Summary: Support for composite unique attributes for a type. Key: ATLAS-1016 URL: https://issues.apache.org/jira/browse/ATLAS-1016 Project: Atlas Issue Type: Improvement Affects Versions: 0.8-incubating Reporter: Satish Duggana Fix For: 0.8-incubating Currently atlas types support attributes containing unique attributes. Enhance this to support composite unique attributes. For example, DeviceInfo has attributes like name, model, version and timestamp. Any of these attributes can be configured unique constraint. There should be a way to set composite unique constraint on both model and version fields so that it should not allow storing entities having same set of values for both model and version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ATLAS-1015) ClassCastException: scala.math.BigInt cannot be cast to java.lang.Long for an attribute with data type as Long.
Satish Duggana created ATLAS-1015:
-
Summary: ClassCastException: scala.math.BigInt cannot be cast to
java.lang.Long for an attribute with data type as Long.
Key: ATLAS-1015
URL: https://issues.apache.org/jira/browse/ATLAS-1015
Project: Atlas
Issue Type: Bug
Affects Versions: 0.8-incubating
Reporter: Satish Duggana
Priority: Critical
Fix For: 0.8-incubating
A type is created with the below info. An entity is created with respective
attributes including the Long value for timestamp. But when that stored entity
is retrieved, it returns a Referenceable with timestamp attribute containing
scala.math.BigInt type instead of java.lang.Long type
{code:java}
TypesUtil.createClassTypeDef(
DeviceInfo.NAME_SPACE, null,
TypesUtil.createUniqueRequiredAttrDef(DeviceInfo.NAME,
DataTypes.STRING_TYPE),
TypesUtil.createUniqueRequiredAttrDef(DeviceInfo.XID,
DataTypes.STRING_TYPE),
attrDef(DeviceInfo.TIMESTAMP, DataTypes.LONG_TYPE),
attrDef(DeviceInfo.VERSION, DataTypes.STRING_TYPE)
);
{code}
You can look at the test code
[here|https://github.com/satishd/incubator-atlas/blob/types-poc/samples/src/test/java/org/apache/atlas/sample/AtlasMetadataServiceTest.java]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ATLAS-1014) Unnecessary locking and double checked locking for a threadlocal in RequestContext.
[
https://issues.apache.org/jira/browse/ATLAS-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Satish Duggana updated ATLAS-1014:
--
Description:
{code:java}
public static RequestContext get() {
if (CURRENT_CONTEXT.get() == null) {
synchronized (RequestContext.class) {
if (CURRENT_CONTEXT.get() == null) {
createContext();
}
}
}
return CURRENT_CONTEXT.get();
}
{code}
There is no need to have double checked locking and synchronization for setting
a threadlocal state. That logic can be removed by adding the below code while
instantiating CURRENT_CONTEXT.
{code:java}
private static final ThreadLocal CURRENT_CONTEXT = new
ThreadLocal() {
@Override
protected RequestContext initialValue() {
RequestContext context = new RequestContext();
context.requestTime = System.currentTimeMillis();
return context;
}
};
{code}
RequestContext#createContext usages can be changed to RequestContext#get
was:
public static RequestContext get() {
if (CURRENT_CONTEXT.get() == null) {
synchronized (RequestContext.class) {
if (CURRENT_CONTEXT.get() == null) {
createContext();
}
}
}
return CURRENT_CONTEXT.get();
}
There is no need to have double checked locking and synchronization for setting
current thread's state. That logic can be removed by adding the below code
while instantiating CURRENT_CONTEXT.
``` java
private static final ThreadLocal CURRENT_CONTEXT = new
ThreadLocal() {
@Override
protected RequestContext initialValue() {
RequestContext context = new RequestContext();
context.requestTime = System.currentTimeMillis();
return context;
}
};
```
RequestContext#createContext usages can be changed to RequestContext#get
> Unnecessary locking and double checked locking for a threadlocal in
> RequestContext.
> ---
>
> Key: ATLAS-1014
> URL: https://issues.apache.org/jira/browse/ATLAS-1014
> Project: Atlas
> Issue Type: Task
>Reporter: Satish Duggana
>
> {code:java}
> public static RequestContext get() {
> if (CURRENT_CONTEXT.get() == null) {
> synchronized (RequestContext.class) {
> if (CURRENT_CONTEXT.get() == null) {
> createContext();
> }
> }
> }
> return CURRENT_CONTEXT.get();
> }
> {code}
> There is no need to have double checked locking and synchronization for
> setting a threadlocal state. That logic can be removed by adding the below
> code while instantiating CURRENT_CONTEXT.
> {code:java}
> private static final ThreadLocal CURRENT_CONTEXT = new
> ThreadLocal() {
> @Override
> protected RequestContext initialValue() {
> RequestContext context = new RequestContext();
> context.requestTime = System.currentTimeMillis();
> return context;
> }
> };
> {code}
> RequestContext#createContext usages can be changed to RequestContext#get
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ATLAS-1014) Unnecessary locking and double checked locking for a threadlocal in RequestContext.
[
https://issues.apache.org/jira/browse/ATLAS-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Satish Duggana updated ATLAS-1014:
--
Description:
public static RequestContext get() {
if (CURRENT_CONTEXT.get() == null) {
synchronized (RequestContext.class) {
if (CURRENT_CONTEXT.get() == null) {
createContext();
}
}
}
return CURRENT_CONTEXT.get();
}
There is no need to have double checked locking and synchronization for setting
current thread's state. That logic can be removed by adding the below code
while instantiating CURRENT_CONTEXT.
``` java
private static final ThreadLocal CURRENT_CONTEXT = new
ThreadLocal() {
@Override
protected RequestContext initialValue() {
RequestContext context = new RequestContext();
context.requestTime = System.currentTimeMillis();
return context;
}
};
```
RequestContext#createContext usages can be changed to RequestContext#get
was:
public static RequestContext get() {
if (CURRENT_CONTEXT.get() == null) {
synchronized (RequestContext.class) {
if (CURRENT_CONTEXT.get() == null) {
createContext();
}
}
}
return CURRENT_CONTEXT.get();
}
There is no need to have double checked locking and synchronization for setting
current thread's state. That logic can be removed by adding the below code
while instantiating CURRENT_CONTEXT.
private static final ThreadLocal CURRENT_CONTEXT = new
ThreadLocal<>() {
@Override
protected Object initialValue() {
RequestContext context = new RequestContext();
context.requestTime = System.currentTimeMillis();
return context;
}
};
RequestContext#createContext usages can be changed to RequestContext#get
> Unnecessary locking and double checked locking for a threadlocal in
> RequestContext.
> ---
>
> Key: ATLAS-1014
> URL: https://issues.apache.org/jira/browse/ATLAS-1014
> Project: Atlas
> Issue Type: Task
>Reporter: Satish Duggana
>
> public static RequestContext get() {
> if (CURRENT_CONTEXT.get() == null) {
> synchronized (RequestContext.class) {
> if (CURRENT_CONTEXT.get() == null) {
> createContext();
> }
> }
> }
> return CURRENT_CONTEXT.get();
> }
> There is no need to have double checked locking and synchronization for
> setting current thread's state. That logic can be removed by adding the below
> code while instantiating CURRENT_CONTEXT.
> ``` java
> private static final ThreadLocal CURRENT_CONTEXT = new
> ThreadLocal() {
> @Override
> protected RequestContext initialValue() {
> RequestContext context = new RequestContext();
> context.requestTime = System.currentTimeMillis();
> return context;
> }
> };
> ```
> RequestContext#createContext usages can be changed to RequestContext#get
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ATLAS-1012) DefaultMetadataService#getEntityDefinition(String guid) returns a deleted instance with SoftDeleteHandler
Satish Duggana created ATLAS-1012: - Summary: DefaultMetadataService#getEntityDefinition(String guid) returns a deleted instance with SoftDeleteHandler Key: ATLAS-1012 URL: https://issues.apache.org/jira/browse/ATLAS-1012 Project: Atlas Issue Type: Bug Affects Versions: 0.8-incubating Reporter: Satish Duggana Fix For: 0.8-incubating `DefaultMetadataService#getEntityDefinition(String guid)` returns a deleted instance when atlas.DeleteHandler.impl is configured with `org.apache.atlas.repository.graph.SoftDeleteHandler` Main reason seems to be about not checking for a valid state of the instance before it is returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
