src/query.dart exported

[andriwsluna]

I need to access the class ColumnDescription as FieldDescription to grant access to typeID property of this class.
The class FieldDescription is writed in file "query.dart" thats not exported.

With this information, i can automate proccess im my project.

[isoos]

I think a better way to do it would be to expose the typeID field on ColumnDescription (fewer internal details are exposed, easier to change the implementation). Could you please add some detail on the automation part? What's this used for?

[andriwsluna]

With this property I know the real type of the column. With this, I use a generator of typed and static classes to map each column of the table. Without access to typeId, the most I can do is a column with values ​​of type "dynamic".

In addition to the typeID, I also use other FieldDescription properties, such as: maxLen, defaultValue and etc.

See example of generated class in: static_postgres

In order not to have to stop my project, I had to attach a copy of the postgres package to this.

If there is another way (like an extension) to not have to expose this class in your package, I will do it.

[isoos]

In addition to the typeID, I also use other FieldDescription properties, such as: maxLen, defaultValue and etc.

I'm not sure I follow: how do you know these properties from these? https://github.com/isoos/postgresql-dart/blob/master/lib/src/query.dart#L235-L248

If there is another way (like an extension) to not have to expose this class in your package, I will do it.

I think it is reasonable to expose some of the properties from FieldDescription, however:

• I'm not happy with the naming conventions of the fields there, so maybe I'd expose them as different names through the ColumnDescription interface
• In a future refactor FieldDescription is potentially a candidate for a breaking change, so I'd expose only fields that will probably remain in the future too.

[andriwsluna]

I'm not sure I follow: how do you know these properties from these?

Forgiveness. There was a mistake on my part. I just need the typeID.

I'm not happy with the naming conventions of the fields there, so maybe I'd expose them as different names through the ColumnDescription interface

If ColumnDescription exposes typeID, even if with another name, it is satisfactory for me.So the package would not need to export query.dart

[isoos]

@andriwsluna Maybe you know this better: is typeID the same as oid?

[isoos]

@andriwsluna Maybe you know this better: is typeID the same as oid?

I think I can answer this: it looks like typeID is the oid of the type. How about we call it typeOid in the exposed interface?

[andriwsluna]

@andriwsluna Maybe you know this better: is typeID the same as oid?

Yes.

[andriwsluna]

@andriwsluna Maybe you know this better: is typeID the same as oid?

I think I can answer this: it looks like typeID is the oid of the type. How about we call it typeOid in the exposed interface?

typeOid seems more correct, but typeId is more understandable to people in general. In this case, I would choose typeOid.

[isoos]

I've published 2.3.2 with typeId. I have tried to get some inspiration from other languages, and *Id was used, while I haven't seen *Oid at other places.

[andriwsluna]

Thanks