ldap and predefined fields

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

ldap and predefined fields

dcrissman
Lightblue will automatically add certain fields to an entity's metadata, I am not sure how other datasources are handling this, but I have some concerns about it as it pertains to LDAP.
eg. "array#":size or objectType

Firstly, '#' does not appear to be a valid character for attribute names in LDAP

Secondly, LDAP has the concept of "objectClass", which is essentially a list of interfaces that defines what attributes are allowed on that entity. So we would have to somehow have the array size attributes defined in an objectClass, which is not a realistic expectation.

Thirdly, LDAP is likely going to be maintained by other admin portals, so keeping the array sizes in sync would be a problem.

* How is objectType being used?
* How are we using the array sizes today?
* How are other implementations handling this? I would imagine RDBMs would have a similar issue if every array field requires an array size column also. Are they just being stripped out of the inserts?
* Would it be possible to make these predefined fields optional or modifiable somehow?
* It might be useful if the Field somehow indicated that it was auto-generated?
Reply | Threaded
Open this post in threaded view
|

Re: ldap and predefined fields

bserdar
objectType gives the metadata entity name. It is the object type. You
can have different types of entities in a collection, so objectType
lets you limit the scope to a particular type of object.

Array sizes are there so you can search by the size of an array field
in an object,

I don't think RDBMS is handling array sizes.

It *might* be OK to simply say array size searches are not supported
for RDBMS and LDAP. You can set array sizes before returning the
objects, and never store them.

Predefined fields are not optional. If back end doesn't support it, it
has to deal with it.

Why would a flag for auto-generation be useful? Why do you need to
know if a value is generated, or assigned by the caller?


On Wed, Jan 7, 2015 at 12:52 PM, dcrissman [via lightblue-dev]
<[hidden email]> wrote:

> Lightblue will automatically add certain fields to an entity's metadata, I
> am not sure how other datasources are handling this, but I have some
> concerns about it as it pertains to LDAP.
> eg. "array#":size or objectType
>
> Firstly, '#' does not appear to be a valid character for attribute names in
> LDAP
>
> Secondly, LDAP has the concept of "objectClass", which is essentially a list
> of interfaces that defines what attributes are allowed on that entity. So we
> would have to somehow have the array size attributes defined in an
> objectClass, which is not a realistic expectation.
>
> Thirdly, LDAP is likely going to be maintained by other admin portals, so
> keeping the array sizes in sync would be a problem.
>
> * How is objectType being used?
> * How are we using the array sizes today?
> * How are other implementations handling this? I would imagine RDBMs would
> have a similar issue if every array field requires an array size column
> also. Are they just being stripped out of the inserts?
> * Would it be possible to make these predefined fields optional or
> modifiable somehow?
> * It might be useful if the Field somehow indicated that it was
> auto-generated?
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261.html
> To start a new topic under lightblue-dev, email
> [hidden email]
> To unsubscribe from lightblue-dev, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: ldap and predefined fields

jewzaam
Administrator
In reply to this post by dcrissman
+1 to making array count fields optional.  It's in core right now which makes it a problem.  It could be a constraint which would allow any field to represent the count, making the # character issue found with LDAP a non-issue.  As well as not requiring it always, it would be up to the metadata definition.

On Wed Jan 07 2015 at 2:52:56 PM dcrissman [via lightblue-dev] <[hidden email]> wrote:
Lightblue will automatically add certain fields to an entity's metadata, I am not sure how other datasources are handling this, but I have some concerns about it as it pertains to LDAP.
eg. "array#":size or objectType

Firstly, '#' does not appear to be a valid character for attribute names in LDAP

Secondly, LDAP has the concept of "objectClass", which is essentially a list of interfaces that defines what attributes are allowed on that entity. So we would have to somehow have the array size attributes defined in an objectClass, which is not a realistic expectation.

Thirdly, LDAP is likely going to be maintained by other admin portals, so keeping the array sizes in sync would be a problem.

* How is objectType being used?
* How are we using the array sizes today?
* How are other implementations handling this? I would imagine RDBMs would have a similar issue if every array field requires an array size column also. Are they just being stripped out of the inserts?
* Would it be possible to make these predefined fields optional or modifiable somehow?
* It might be useful if the Field somehow indicated that it was auto-generated?



If you reply to this email, your message will be added to the discussion below:
http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261.html
To start a new topic under lightblue-dev, email [hidden email]
To unsubscribe from lightblue-dev, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: ldap and predefined fields

jewzaam
Administrator
In reply to this post by bserdar
The only way to remove objectType would require some work per backend.  For mongo, we'd have to ensure that every entity was stored in a separate collection.  Dont' think RDBMS would have a problem with this.  Likely same with LDAP.

On Wed Jan 07 2015 at 3:02:19 PM bserdar [via lightblue-dev] <[hidden email]> wrote:
objectType gives the metadata entity name. It is the object type. You
can have different types of entities in a collection, so objectType
lets you limit the scope to a particular type of object.

Array sizes are there so you can search by the size of an array field
in an object,

I don't think RDBMS is handling array sizes.

It *might* be OK to simply say array size searches are not supported
for RDBMS and LDAP. You can set array sizes before returning the
objects, and never store them.

Predefined fields are not optional. If back end doesn't support it, it
has to deal with it.

Why would a flag for auto-generation be useful? Why do you need to
know if a value is generated, or assigned by the caller?


On Wed, Jan 7, 2015 at 12:52 PM, dcrissman [via lightblue-dev]
<[hidden email]> wrote:

> Lightblue will automatically add certain fields to an entity's metadata, I
> am not sure how other datasources are handling this, but I have some
> concerns about it as it pertains to LDAP.
> eg. "array#":size or objectType
>
> Firstly, '#' does not appear to be a valid character for attribute names in
> LDAP
>
> Secondly, LDAP has the concept of "objectClass", which is essentially a list
> of interfaces that defines what attributes are allowed on that entity. So we
> would have to somehow have the array size attributes defined in an
> objectClass, which is not a realistic expectation.
>
> Thirdly, LDAP is likely going to be maintained by other admin portals, so
> keeping the array sizes in sync would be a problem.
>
> * How is objectType being used?
> * How are we using the array sizes today?
> * How are other implementations handling this? I would imagine RDBMs would
> have a similar issue if every array field requires an array size column
> also. Are they just being stripped out of the inserts?
> * Would it be possible to make these predefined fields optional or
> modifiable somehow?
> * It might be useful if the Field somehow indicated that it was
> auto-generated?
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261.html
> To start a new topic under lightblue-dev, email
> To unsubscribe from lightblue-dev, click here.
> NAML
If you reply to this email, your message will be added to the discussion below:
To start a new topic under lightblue-dev, email [hidden email]
To unsubscribe from lightblue-dev, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: ldap and predefined fields

bserdar
In reply to this post by jewzaam
The # character is not an issue. You can map names to something
acceptable to the back end. You are expected to do such mappings at
the translation phase.

Array sizes might be made optional. Instead of a constraint, we can
simply use "arrayName#" as the array size field. If it is there, it
would be populated.

On Wed, Jan 7, 2015 at 1:03 PM, jewzaam [via lightblue-dev]
<[hidden email]> wrote:

> +1 to making array count fields optional.  It's in core right now which
> makes it a problem.  It could be a constraint which would allow any field to
> represent the count, making the # character issue found with LDAP a
> non-issue.  As well as not requiring it always, it would be up to the
> metadata definition.
>
> On Wed Jan 07 2015 at 2:52:56 PM dcrissman [via lightblue-dev] <[hidden
> email]> wrote:
>>
>> Lightblue will automatically add certain fields to an entity's metadata, I
>> am not sure how other datasources are handling this, but I have some
>> concerns about it as it pertains to LDAP.
>> eg. "array#":size or objectType
>>
>> Firstly, '#' does not appear to be a valid character for attribute names
>> in LDAP
>>
>> Secondly, LDAP has the concept of "objectClass", which is essentially a
>> list of interfaces that defines what attributes are allowed on that entity.
>> So we would have to somehow have the array size attributes defined in an
>> objectClass, which is not a realistic expectation.
>>
>> Thirdly, LDAP is likely going to be maintained by other admin portals, so
>> keeping the array sizes in sync would be a problem.
>>
>> * How is objectType being used?
>> * How are we using the array sizes today?
>> * How are other implementations handling this? I would imagine RDBMs would
>> have a similar issue if every array field requires an array size column
>> also. Are they just being stripped out of the inserts?
>> * Would it be possible to make these predefined fields optional or
>> modifiable somehow?
>> * It might be useful if the Field somehow indicated that it was
>> auto-generated?
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261.html
>> To start a new topic under lightblue-dev, email [hidden email]
>> To unsubscribe from lightblue-dev, click here.
>> NAML
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261p264.html
> To start a new topic under lightblue-dev, email
> [hidden email]
> To unsubscribe from lightblue-dev, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: ldap and predefined fields

bserdar
In reply to this post by jewzaam
objectType should not be removed. A lot of things depend on object
type being in the document. For LDAP, ignore objectType on the way in
(but make sure it is not something unexpected), and add it back on the
way out.

On Wed, Jan 7, 2015 at 1:05 PM, jewzaam [via lightblue-dev]
<[hidden email]> wrote:

> The only way to remove objectType would require some work per backend.  For
> mongo, we'd have to ensure that every entity was stored in a separate
> collection.  Dont' think RDBMS would have a problem with this.  Likely same
> with LDAP.
>
> On Wed Jan 07 2015 at 3:02:19 PM bserdar [via lightblue-dev] <[hidden
> email]> wrote:
>>
>> objectType gives the metadata entity name. It is the object type. You
>> can have different types of entities in a collection, so objectType
>> lets you limit the scope to a particular type of object.
>>
>> Array sizes are there so you can search by the size of an array field
>> in an object,
>>
>> I don't think RDBMS is handling array sizes.
>>
>> It *might* be OK to simply say array size searches are not supported
>> for RDBMS and LDAP. You can set array sizes before returning the
>> objects, and never store them.
>>
>> Predefined fields are not optional. If back end doesn't support it, it
>> has to deal with it.
>>
>> Why would a flag for auto-generation be useful? Why do you need to
>> know if a value is generated, or assigned by the caller?
>>
>>
>> On Wed, Jan 7, 2015 at 12:52 PM, dcrissman [via lightblue-dev]
>> <[hidden email]> wrote:
>>
>> > Lightblue will automatically add certain fields to an entity's metadata,
>> > I
>> > am not sure how other datasources are handling this, but I have some
>> > concerns about it as it pertains to LDAP.
>> > eg. "array#":size or objectType
>> >
>> > Firstly, '#' does not appear to be a valid character for attribute names
>> > in
>> > LDAP
>> >
>> > Secondly, LDAP has the concept of "objectClass", which is essentially a
>> > list
>> > of interfaces that defines what attributes are allowed on that entity.
>> > So we
>> > would have to somehow have the array size attributes defined in an
>> > objectClass, which is not a realistic expectation.
>> >
>> > Thirdly, LDAP is likely going to be maintained by other admin portals,
>> > so
>> > keeping the array sizes in sync would be a problem.
>> >
>> > * How is objectType being used?
>> > * How are we using the array sizes today?
>> > * How are other implementations handling this? I would imagine RDBMs
>> > would
>> > have a similar issue if every array field requires an array size column
>> > also. Are they just being stripped out of the inserts?
>> > * Would it be possible to make these predefined fields optional or
>> > modifiable somehow?
>> > * It might be useful if the Field somehow indicated that it was
>> > auto-generated?
>> >
>> >
>> > ________________________________
>> > If you reply to this email, your message will be added to the discussion
>> > below:
>> > http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261.html
>> > To start a new topic under lightblue-dev, email
>> > [hidden email]
>> > To unsubscribe from lightblue-dev, click here.
>> > NAML
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261p263.html
>> To start a new topic under lightblue-dev, email [hidden email]
>> To unsubscribe from lightblue-dev, click here.
>> NAML
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261p265.html
> To start a new topic under lightblue-dev, email
> [hidden email]
> To unsubscribe from lightblue-dev, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: ldap and predefined fields

jewzaam
Administrator
Things depend on it now, but it's possibly redundant.  Not likely for RDBMS backend we're doing anything to save it, especially since the use case for us is most likely going to be existing data structures that won't change.  Guess it would be hard coded.

On Wed Jan 07 2015 at 3:21:52 PM bserdar [via lightblue-dev] <[hidden email]> wrote:
objectType should not be removed. A lot of things depend on object
type being in the document. For LDAP, ignore objectType on the way in
(but make sure it is not something unexpected), and add it back on the
way out.

On Wed, Jan 7, 2015 at 1:05 PM, jewzaam [via lightblue-dev]
<[hidden email]> wrote:

> The only way to remove objectType would require some work per backend.  For
> mongo, we'd have to ensure that every entity was stored in a separate
> collection.  Dont' think RDBMS would have a problem with this.  Likely same
> with LDAP.
>
> On Wed Jan 07 2015 at 3:02:19 PM bserdar [via lightblue-dev] <[hidden
> email]> wrote:

>>
>> objectType gives the metadata entity name. It is the object type. You
>> can have different types of entities in a collection, so objectType
>> lets you limit the scope to a particular type of object.
>>
>> Array sizes are there so you can search by the size of an array field
>> in an object,
>>
>> I don't think RDBMS is handling array sizes.
>>
>> It *might* be OK to simply say array size searches are not supported
>> for RDBMS and LDAP. You can set array sizes before returning the
>> objects, and never store them.
>>
>> Predefined fields are not optional. If back end doesn't support it, it
>> has to deal with it.
>>
>> Why would a flag for auto-generation be useful? Why do you need to
>> know if a value is generated, or assigned by the caller?
>>
>>
>> On Wed, Jan 7, 2015 at 12:52 PM, dcrissman [via lightblue-dev]
>> <[hidden email]> wrote:
>>
>> > Lightblue will automatically add certain fields to an entity's metadata,
>> > I
>> > am not sure how other datasources are handling this, but I have some
>> > concerns about it as it pertains to LDAP.
>> > eg. "array#":size or objectType
>> >
>> > Firstly, '#' does not appear to be a valid character for attribute names
>> > in
>> > LDAP
>> >
>> > Secondly, LDAP has the concept of "objectClass", which is essentially a
>> > list
>> > of interfaces that defines what attributes are allowed on that entity.
>> > So we
>> > would have to somehow have the array size attributes defined in an
>> > objectClass, which is not a realistic expectation.
>> >
>> > Thirdly, LDAP is likely going to be maintained by other admin portals,
>> > so
>> > keeping the array sizes in sync would be a problem.
>> >
>> > * How is objectType being used?
>> > * How are we using the array sizes today?
>> > * How are other implementations handling this? I would imagine RDBMs
>> > would
>> > have a similar issue if every array field requires an array size column
>> > also. Are they just being stripped out of the inserts?
>> > * Would it be possible to make these predefined fields optional or
>> > modifiable somehow?
>> > * It might be useful if the Field somehow indicated that it was
>> > auto-generated?
>> >
>> >
>> > ________________________________
>> > If you reply to this email, your message will be added to the discussion
>> > below:
>> > http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261.html
>> > To start a new topic under lightblue-dev, email
>> > [hidden email]
>> > To unsubscribe from lightblue-dev, click here.
>> > NAML
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261p263.html
>> To start a new topic under lightblue-dev, email [hidden email]
>> To unsubscribe from lightblue-dev, click here.
>> NAML
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:

> To start a new topic under lightblue-dev, email
> [hidden email]
> To unsubscribe from lightblue-dev, click here.
> NAML
If you reply to this email, your message will be added to the discussion below:
To start a new topic under lightblue-dev, email [hidden email]
To unsubscribe from lightblue-dev, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: ldap and predefined fields

bserdar
Note that objectType doesn't have to be persisted. The only
requirement is that the documents returned by the back end has
objectType set correctly.

On Wed, Jan 7, 2015 at 1:37 PM, jewzaam [via lightblue-dev]
<[hidden email]> wrote:

> Things depend on it now, but it's possibly redundant.  Not likely for RDBMS
> backend we're doing anything to save it, especially since the use case for
> us is most likely going to be existing data structures that won't change.
> Guess it would be hard coded.
>
> On Wed Jan 07 2015 at 3:21:52 PM bserdar [via lightblue-dev] <[hidden
> email]> wrote:
>>
>> objectType should not be removed. A lot of things depend on object
>> type being in the document. For LDAP, ignore objectType on the way in
>> (but make sure it is not something unexpected), and add it back on the
>> way out.
>>
>> On Wed, Jan 7, 2015 at 1:05 PM, jewzaam [via lightblue-dev]
>> <[hidden email]> wrote:
>>
>> > The only way to remove objectType would require some work per backend.
>> > For
>> > mongo, we'd have to ensure that every entity was stored in a separate
>> > collection.  Dont' think RDBMS would have a problem with this.  Likely
>> > same
>> > with LDAP.
>> >
>> > On Wed Jan 07 2015 at 3:02:19 PM bserdar [via lightblue-dev] <[hidden
>> > email]> wrote:
>>
>> >>
>> >> objectType gives the metadata entity name. It is the object type. You
>> >> can have different types of entities in a collection, so objectType
>> >> lets you limit the scope to a particular type of object.
>> >>
>> >> Array sizes are there so you can search by the size of an array field
>> >> in an object,
>> >>
>> >> I don't think RDBMS is handling array sizes.
>> >>
>> >> It *might* be OK to simply say array size searches are not supported
>> >> for RDBMS and LDAP. You can set array sizes before returning the
>> >> objects, and never store them.
>> >>
>> >> Predefined fields are not optional. If back end doesn't support it, it
>> >> has to deal with it.
>> >>
>> >> Why would a flag for auto-generation be useful? Why do you need to
>> >> know if a value is generated, or assigned by the caller?
>> >>
>> >>
>> >> On Wed, Jan 7, 2015 at 12:52 PM, dcrissman [via lightblue-dev]
>> >> <[hidden email]> wrote:
>> >>
>> >> > Lightblue will automatically add certain fields to an entity's
>> >> > metadata,
>> >> > I
>> >> > am not sure how other datasources are handling this, but I have some
>> >> > concerns about it as it pertains to LDAP.
>> >> > eg. "array#":size or objectType
>> >> >
>> >> > Firstly, '#' does not appear to be a valid character for attribute
>> >> > names
>> >> > in
>> >> > LDAP
>> >> >
>> >> > Secondly, LDAP has the concept of "objectClass", which is essentially
>> >> > a
>> >> > list
>> >> > of interfaces that defines what attributes are allowed on that
>> >> > entity.
>> >> > So we
>> >> > would have to somehow have the array size attributes defined in an
>> >> > objectClass, which is not a realistic expectation.
>> >> >
>> >> > Thirdly, LDAP is likely going to be maintained by other admin
>> >> > portals,
>> >> > so
>> >> > keeping the array sizes in sync would be a problem.
>> >> >
>> >> > * How is objectType being used?
>> >> > * How are we using the array sizes today?
>> >> > * How are other implementations handling this? I would imagine RDBMs
>> >> > would
>> >> > have a similar issue if every array field requires an array size
>> >> > column
>> >> > also. Are they just being stripped out of the inserts?
>> >> > * Would it be possible to make these predefined fields optional or
>> >> > modifiable somehow?
>> >> > * It might be useful if the Field somehow indicated that it was
>> >> > auto-generated?
>> >> >
>> >> >
>> >> > ________________________________
>> >> > If you reply to this email, your message will be added to the
>> >> > discussion
>> >> > below:
>> >> > http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261.html
>> >> > To start a new topic under lightblue-dev, email
>> >> > [hidden email]
>> >> > To unsubscribe from lightblue-dev, click here.
>> >> > NAML
>> >> If you reply to this email, your message will be added to the
>> >> discussion
>> >> below:
>> >> http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261p263.html
>> >> To start a new topic under lightblue-dev, email [hidden email]
>> >> To unsubscribe from lightblue-dev, click here.
>> >> NAML
>> >
>> >
>> >
>> > ________________________________
>> > If you reply to this email, your message will be added to the discussion
>> > below:
>> > http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261p265.html
>>
>> > To start a new topic under lightblue-dev, email
>> > [hidden email]
>> > To unsubscribe from lightblue-dev, click here.
>> > NAML
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261p268.html
>> To start a new topic under lightblue-dev, email [hidden email]
>> To unsubscribe from lightblue-dev, click here.
>> NAML
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261p269.html
> To start a new topic under lightblue-dev, email
> [hidden email]
> To unsubscribe from lightblue-dev, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: ldap and predefined fields

dcrissman
bserdar wrote
Note that objectType doesn't have to be persisted. The only
requirement is that the documents returned by the back end has
objectType set correctly.
I just pushed up changes that will strip out any field with a name that ends with a # or equals objectType from being persisted to LDAP. Then I programatically handle populating these fields if they are requested.
Reply | Threaded
Open this post in threaded view
|

Re: ldap and predefined fields

dcrissman
In reply to this post by dcrissman
Allow me to change the question around then.

Can predefined fields be added per datatype? For example, an LDAP entry should always have a DN.
Reply | Threaded
Open this post in threaded view
|

Re: ldap and predefined fields

bserdar
CRUDController.getMetadataListener() -> use this to intercept metadata
updates and you can add whatever you want
CRUDController.updatePredefinedFields() -> This deals with updating
backend specific fields before ins/update

On Thu, Jan 8, 2015 at 10:18 AM, dcrissman [via lightblue-dev]
<[hidden email]> wrote:

> Allow me to change the question around then.
>
> Can predefined fields be added per datatype? For example, an LDAP entry
> should always have a DN.
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev.forum.lightblue.io/ldap-and-predefined-fields-tp261p274.html
> To start a new topic under lightblue-dev, email
> [hidden email]
> To unsubscribe from lightblue-dev, click here.
> NAML