Hi Luke:
I feel this discussion is getting somewhere.
> My reasoning was this:
>
> If content is not unique, or at least probably unique, you will probably end
> up with many copies of a single document being attached, to for example, a
> quote, an order, an invoice, possibly a purchase order, a
On Tue, 5 Jul 2011, Chris Travers wrote:
I guess there is one thing that's bothering me about this discussion,
The thing that bothers me (slightly) is that you and I seem to be the only
people with opinions on this.
and it's worth bringing up. I am not aware of a single filesystem
which a
On Mon, Jul 4, 2011 at 9:05 PM, Luke wrote:
> Seems reasonable enough. So instead of being unique to the filename, you'd
> be unique to the filename and the source attachment point?
>
> The problem I see there, is what happens if order 42 is deleted after the
> consolidation?
> To prevent that,
On Mon, 4 Jul 2011, Chris Travers wrote:
On Mon, Jul 4, 2011 at 12:33 PM, Luke wrote:
However, if we combine our two ways of looking at this, I think we have
the solution.
If you store files by ID, and internally reference them by ID at all
times, they can all be called "foobar.pdf" and it d
On Mon, Jul 4, 2011 at 7:21 PM, Luke wrote:
> On Mon, 4 Jul 2011, Chris Travers wrote:
>
>> CREATE TABLE file_storage (
>> content bytea,
>> mime_type int,
>> id serial not null unique,
>> PRIMARY KEY (content, mime_type),
>> );
>
> Aside from everything:
>
> Should mime_type be an int? What are
On Mon, 4 Jul 2011, Chris Travers wrote:
> CREATE TABLE file_storage (
> content bytea,
> mime_type int,
> id serial not null unique,
> PRIMARY KEY (content, mime_type),
> );
Aside from everything:
Should mime_type be an int? What are you going to be putting in it?
How can we be sure that the
On Mon, Jul 4, 2011 at 12:33 PM, Luke wrote:
>>> However, if we combine our two ways of looking at this, I think we have
>>> the solution.
>>>
>>> If you store files by ID, and internally reference them by ID at all
>>> times, they can all be called "foobar.pdf" and it doesn't matter.
>>
>> Ok, s
On Mon, 4 Jul 2011, Chris Travers wrote:
On Sun, Jul 3, 2011 at 11:28 PM, Luke wrote:
I was expecting that, yes. However, I shouldn't. My recent experience is
with reasonably disciplined corporate users, who either get files from
sources with likely to be unique names (some form of the vend
On Sun, Jul 3, 2011 at 11:28 PM, Luke wrote:
> I was expecting that, yes. However, I shouldn't. My recent experience is
> with reasonably disciplined corporate users, who either get files from
> sources with likely to be unique names (some form of the vendor name and
> vendor's ID), create file
On Sat, 2 Jul 2011, Chris Travers wrote:
> On Sat, Jul 2, 2011 at 1:16 PM, Luke wrote:
>
>> Probably though, as I think about it, this would require globally unique
>> filenames, and a name comparison with new uploads, possibly followed by a
>> content comparison if names match.
>> I'm not sure g
On Sat, Jul 2, 2011 at 1:16 PM, Luke wrote:
>
> You would have to replicate the handling for other documents, right? I.E.
> quotes, payments, etc.
transactions would be ar/ap transactions, sales/vendor invoices, GL
transactions.
order would be sales/purchase orders, RFQ's and quotations.
>
>>
On Sat, 2 Jul 2011, Chris Travers wrote:
> On Sat, Jul 2, 2011 at 5:26 AM, Erik Huelsmann wrote:
>
>> It's not clear to me what we need the different attachment classes for.
>> Could you explain what you want to use them for? Isn't a file just a file?
>
> The file_base table is essentially a part
On Sat, Jul 2, 2011 at 5:26 AM, Erik Huelsmann wrote:
> Great! Especially the SQL part. As we discussed on IRC before, it would be
> a very nice signal to users of our APIs if we could document which SQL
> functions we consider public and which we consider non-public, assuming our
> public API w
Hi Chris,
Sorry for the late reaction. I'm only now ready to follow up to your
questions below.
> The current approach I am taking is to use table inheritance to
> provide a consistent set of tables with different foreign keys.
> Constraints would first-and-foremost be enforced in the database
Hi all;
So when the next beta ships I will start on adding file attachments to
AR. AP, GL, and order entry items. This current approach is to
discuss API proposals rather than the usability side. I will submit a
usability proposal to the -users list once this side is complete.
The current appro
15 matches
Mail list logo
